Messages in this thread | | | Date | Thu, 7 Oct 1999 17:58:52 -0700 (PDT) | From | Matthew Dharm <> | Subject | Re: PUBLIC CHALLENGE: (was RE: devfs again, (was RE: USB device a lloc ation) ) |
| |
On Thu, 7 Oct 1999, Horst von Brand wrote:
> Reasons against devfs: > > - Permanent attributes are kludged on
If the driver is supplying defaults, I don't really see this as kludged. At least, no more than MAKEDEV is a kludge to set up /dev properly.
> - Breaks filesystem semantics in several ways, makes it very hard to check > ramifications
Please elaborate. I have yet to see you describe one case where the semantics are broken. If you can, please provide code/commands/a scenario in which devfs does "the wrong thing" with respect to filesystems.
> - Impacts system administration, making device managing a lot less Unixy
Duh. Every driver impacts system administration. Devfs is no different from having a printer in that respect.
BTW, on this note, how do you react to /dev/pts/? Seems very similar to me....
> - Impacts _every_ single driver in the kernel, even if it isn't used
How? If the driver has no devfs interaction (only via traditional /dev/), how is it impacted? Nobody is saying that _all_ drivers, throughout the kernel and all of history, must be re-written.
> - What can be done with devfs can be done without it. Granted, it is less > convenient. But I add/remove devices from my machines perhaps once a > month, so that doesn't cut it for me.
Just because you only remove/add devices once a month is no reason to oppose devfs. I don't change devices much either, but as a developer the rules are that we should be as flexible as possible. And as for less convenient... I would really like it if hot-swap could operate without having to have someone with root access at the machine to configure the new USB mouse I just plugged in.
> Reasons for devfs: > > - Makes handling hot-plug easier, but marginally so
I don't view this as marginal, by any means. The presence of widely available bus technologies which are designed and intended to support hundreds of various devices _simultaneously_ means that there is nothing 'marginal' about it.
> - Unclutters /dev
Given. But I don't really care about this one.
> Also: It is extra code, has to be maintained and updated, and has to be > accounted for in new driver developments. It _will_ add new bugs, even new > classes of bugs. This doesn't come for free.
Ooohh... extra code. Gee, you know, you better detach that printer... using it causes extra code to be used by your computer.
If every time someone thought of a new and better way to do something, people stopped him because it would add 'extra code' and possibly introduce a 'new class of bug', we'd still be using the abacus.
> Weighting the above, the answer for me is clearly "no".
Fine. But, as I've pointed out above, there is no reason you have to use devfs, if it's present. So you don't. Don't try to tie the hands of developers because this wouldn't be advantageous to you.
So far, all I see in your messages is that you personally oppose it, for reasons which are very centered around the way you use your computer. You must consider the full range of potential users when presenting your arguments, or they make no sense. (BTW, I think that's microsoft's problem.... they only consider the common case, not the full range of possibilities.)
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-8155
S: Another stupid question? G: There's no such thing as a stupid question, only stupid people. -- Stef and Greg User Friendly, 7/15/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/
| |