<sarcasm>
Why are there such many different networking audio wrappers for the
sound devices out there and why shouldn't you in applications try to use
them directly? Maybe the interface you are talking about isn't enough?
</sarcasm>
> 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?
<sarcasm>
It's not different indeed. It's exposing the application writer with
all the same problems as the sound example does.
</sarcams>
> Just in that the files in /dev are real system files taking up file space,
> and the files in /proc are dynamic,
<sarcams>
The "files" in /dev/ don't take real file space they take just a one single
inode.
</sarcams>
> linked right into the kernel without the disadvantages of major/minor
> numbers.
<sarcams>
A:\ C:\ D:\
(dos and ofther inferiors..)
"disk1@centralofficeintherearthere"[somwhere:sadfhjsjdfk:sdfsdf]/asdfsdf/sdfsdf/sdfsdf
(^^^ supposed to be VMS alike)
Are much much better then the concept of minor/major numbers for the user.
</sarcams>
> > system... And now they are eager to introduce
> > even more of this kind of stuff (Ahhh a tar cf blah /dev/* triggered
> > from kernel
> > level for persistency! WODERFULLL!). Ugh not too long in the future this
> > all will
> > be looking quite like the >Registry< just even worser becouse entierly
> > inside
> > the kernel. Ehh... And there is still the question how they will explain
>
> By the way, I don't think that the 'tar cf' is a bad solution, and I also
> don't think the registry is a bad solution (although in windows 95 it was
> definately badly implemented).
>
> I also don't think either should be kernel level, a registry daemon could be
> started in init, the same as
> parsing or creating that tar file.
>
> data is data, whether in a real filesystem with inodes or in a virtual
> filesystem.
>
> Anyways, the problem is that we are getting to the point where exotic
> hardware is _not_ an academic excersise. Someone could hook up 8 keyboards
> and 8 mice with a scanner and a printer for 8 lab stations today if it was
> supported. I should say _would_, the cost-conserned department would jump at
> the chance to get a single system to manage 8 stations, and perhaps only
> have ten computers requiring maintenance in the entire lab. But of course
> this is impossible today.
>
> We have an arbitrary limitation in place for absolutely no good reason,
> other than that it seems to some people to be easier to work around it
> forever than to actually think up a good solution and change it.
>
> I personally don't think devfs is the best solution, because it still uses
> the major/minor system. I think we need to figure out how to handle access
> to hardware that will not only not definately be there on reboot, but might
> not be there from one minute to the next.
--Marcin
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/