lkml.org 
[lkml]   [1999]   [Oct]   [12]   [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 Mon, 11 Oct 1999, Horst von Brand wrote:

> > > - Permanent attributes are kludged on
>
> > True, but it works. It's no more kludged than some other stuff in the
> > kernel (remember umsdos?). Less kludged actually.
>
> If an ugly, evil klutz as umsdos is your standard...

It's not my standard, but another example of an ugly kludge that works and
is useful nevertheless.

> > Also, the current USB device naming system in 2.3.20 is a very ugly kludge
> > that can go away with devfs.
>
> It could go away in other ways to. Why _must_ it be devfs?

Nobody is saying it _must_ be devfs (at least I'm not). Devfs is a
possible solution though, and we have it right now, and it makes a lot of
other things easier, especially for newbies.
Advanced users who for whatever reasons don't like it can just turn it
off.

> > > - Breaks filesystem semantics in several ways, makes it very hard to check
> > > ramifications
>
> > How so? I don't see it breaking anything.
>
> Persistence. Try adding ACLs cleanly.

Cleanly: granted, this is a problem.
Kludgy: possible without any major implications.

> > > - Impacts system administration,
> > by making things easier...
> ... and others impossible/hard.

Such as?

> > > making device managing a lot less Unixy
> > FreeBSD has devfs. Is FreeBSD not Unix?
>
> Never looked into that.

Have a look at FreeBSD 4.0-CURRENT to see an example of a working devfs
that is more widely in use than the Linux patches...

> > > - Impacts _every_ single driver in the kernel, even if it isn't used
>
> > Only at the source level if CONFIG_DEVFS is not set, and the changes
> > needed at source level are so minimal that someone with no previous kernel
> > programming experience could do it in half an hour.
>
> If it is set, it impacts all over.

True.

> Bloat;

That's a matter of opinion. You can consider anything bload. We don't
really "need" kmod, /dev/pts, a.out (anyone still using that?),
chipset-specific IDE support, khttpd, knfsd, isapnp or pcmcia (the latter
two have been implemented without the main kernel supporting them) in the
kernel either - are all of those bloat too?

> stability and security suffer.

How so?
I haven't seen stability problems with devfs even though I'm using it on
Linux and FreeBSD.
Unless you think of someone editing the permissions file (writable by root
only), I don't see security problems either - and once someone can write
to a root-writable file, you're in trouble anyways.
Am I missing something?

> > The key point being *for you*. There are people (PCMCIA, USB, Firewire,
> > ...) who do add/remove devices frequently.
>
> The _same_ devices all the time.

Really? I, for example, use PCMCIA to connect my notebook with a D-Link
DE640 to my home network, or with a Trust EtherLink PCMCIA at office...

With USB hardware becoming more common, we'll see more problems like that
- connecting computers (especially notebooks) to (different) printers
everywhere, and that's just one of the examples.

> Not that I want /dev/fd0 to appear when I place a diskette in it, and
> dissapear when I take it out.

This is different, because /dev/fd0 is the floppy drive, not the diskette.
You still need to access /dev/fd0 if you want to probe if there is a
floppy drive, or if you need to check if there's a diskette in it, and
such.
But you *don't* necessarily want to have /dev/usbprinter109 when the
specified USB printer is not connected.

> > - Makes handling hot-plug possible without ugly kludges
>
> See above. It is quite possible right now (heck, I do it with a Zip drive
> reasonably often). Haven't seen any kludges.

That's possible only because the Zip drive (parallel port, I presume)
always connects at the same place. This is not guaranteed for connecting
to chains of USB hardware.

> > - Easy possibility for userspace tools to know about installed hardware
> > (Just check /dev/sound to see if there is a soundcard and what it can
> > do!)
>
> Check /proc/devices or something like that. It's _much_ easier, actually.

/proc/devices could be extended to give the same functionality, yes.

> > - Compatibility (with FreeBSD and other BSDs that will take up the
> > solution)
>
> "Compatibility with OSes that will [might?] take up the solution" is the
> wrong way around, isn't it? ;-)

FreeBSD has taken up the solution, and experience shows that mostly
anything that gets into one BSD will be ported to the other BSDs.

> Besides, device naming is a quite local matter;

Until you start writing shell scripts that you want to use on your Linux
and FreeBSD boxes without having to modify all the names.

I agree this is not an important issue though.

> > True. But they won't affect you if you say CONFIG_DEVFS=N.
>
> If the CONFIG_DEVFS handling is badly implemented, it can screw up other
> code, even when disabled.

Right. If. It isn't. Read the patch.

LLaP
bero



-
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.049 / U:0.316 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site