Is this sarcasm? Or are you being sarcastic about my sarcasm? ;-)
I know /dev/sound is not enough to properly manipulate sound hardware. But
manipulating hardware via special files has become "The UNIX Way", my point
is how is the current /dev system different from /proc which you obviously
> > How is this different at all? No really, how? If I can write
> pixels to my
> > screen by writing to a file in
> > dev, how is being able to adjust my LM hardware monitors by writing to a
> > file in /proc different?
> It's not different indeed. It's exposing the application writer with
> all the same problems as the sound example does.
Well applications use both of these. With other operating systems (like
Windows) you get devices without abstraction, and have a different library
and different API for manipulating every single one of them.
> > Just in that the files in /dev are real system files taking up
> file space,
> > and the files in /proc are dynamic,
> The "files" in /dev/ don't take real file space they take just a
> one single
real file space. or were you being sarcastic?
> > linked right into the kernel without the disadvantages of major/minor
> > numbers.
> A:\ C:\ D:\
> (dos and ofther inferiors..)
> (^^^ supposed to be VMS alike)
> Are much much better then the concept of minor/major numbers for the user.
Difference is, Windows actually supports dynamic adding and removing of
devices. So in this example, I would disagree with your sarcasm that they
were better, because in fact they are better. Users don't want to plug in
their printer and make character device files in order to be able to access
it. Especially when the numbers make no sense at all. Or at least, make
varying degrees of sense to how much you hang around the person who invented
the numbering scheme.
By the way, if you have a personal email account, I would appreciate it. You
seem to be posting from 'root@various places'. If this is going to turn
into a sarcasm war rather than work on finding a solution to the problem at
hand, I would prefer not to involve two mailing lists.
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to firstname.lastname@example.org
Please read the FAQ at http://www.tux.org/lkml/