lkml.org 
[lkml]   [1999]   [Oct]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: 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/

\
 
 \ /
  Last update: 2005-03-22 13:54    [W:0.642 / U:0.124 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site