> 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.
Devfs DO NOT need major/minor system. It uses major/minor system for existing
devices to simplify conversation but it's not requirement.
-
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/