> [...]
>
> Don't you see all this is ridiculous? Maintaining /dev is _not_ a minute by
> minute activity, just creating entries for new devices is not enough, not
> by a _long_ shot. Sure, it can be nice sometimes, but not enough to pay for
> any extra cost, IMHO. Instead of a fake filesystem use a real one. It works
> well enough for me, and I still haven't seen any real situation were it
> would not be enough, and far simpler than doing extra stuff. People saying
> that 100Kb on disk for /dev is too much don't count (devfs will cost at
> least that much in RAM). "Clutter" isn't a argument either, you _can_ clean
> it up easily. If you really want to, there isn't any real need to go in
> there most of the time.
The problem is, given the nature of modern hot-swap plug-and-play systems,
maintainding /dev could be a _second-by-second_ activity. Forget minutes.
Clearly, the end goal here is to provide a file-like interface to devices
(as is traditional) while supporting hot-swap plug-and-play. Let's not
forget this -- that's the target we should be aiming for.
I agree that the tarball solution to maintain permissions is a kludge. We
could try to have the device driver select it's own permissions, but that
could also get ugly. The persistance of /dev is probably the best
solution to the permissions/ownership problem, but _only_ if a PnP device
is assigned to the name /dev/ entry when it is attached and removed.
That's a pretty tall order for PnP and hot-swap. The logic and policy
engine involved in that demands a user-space daemon solution (input:
whatever info the device provides and user configuration... output:
execution of commands/ioctls/scripts to make the assignment work).
But, if we're going to have a user-space daemon anyway (and the USB
mailing list seems to think this is necessary, ala PCMCIA), why not take a
different (and IMHO more elegant) approach?
So why not run dynamic allocation on top of /dev? I know... at this point
I've now proposed this solution on two different mailing lists, but I
missed much of the discussion of it on linux-kernel. But I still see no
reason why my idea is a bad one... (To review: allocate a major number or
two to a dynamic pool for hot-swap PnP devices, have the kernel inform a
daemon of device events, and create symlinks to support access to those
device. i.e. /dev/usb0 is a printer, and /dev/lp1 is a symlink to it)
Perhaps I'm just missing something, but why is this a flawed design?
More imporantly, why is this concept _more_ flawed than anything else. It
gives us traditional file-like access to devices... it's extensible to
support more hot-swap PnP systems (FireWire, anyone?)... it places policy
squarely in user-space... it adds little code to the kernel...
So what am I missing?
Matt Dharm
-- Matthew Dharm InterNIC: MDD94 Engineer Cell: (619) 890-6943 Home: mdharm@one-eyed-alien.net Home: (858) 689-1908 Beep: page-matt@one-eyed-alien.net Beep: (858) 621-8155NYET! The evil stops here! -- Pitr User Friendly, 6/22/1998
- 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/