Re: [RFC] devfs API

Rudmer van Dijk (rudmer@legolas.dynup.net)
Tue, 12 Nov 2002 09:44:52 +0100


On Tuesday 12 November 2002 09:04, Theodore Ts'o wrote:
> On Mon, Nov 11, 2002 at 08:49:22PM -0500, Alexander Viro wrote:
> > The only way I'll use devfs is
> > * on a separate testbox devoid of network interfaces
> > * with no users
> > * with no data - disk periodically populated from image on CD.
> >
> > And that's regardless of that cleanup - fixing the interface doesn't solve
> > the internal races, so...
>
> Hi Al,
>
> It's good that you're trying to clean up the devfs code, but...
>
> How many people are actually using devfs these days? I don't like it
> myself, and I've had to add a fair amount of hair to fsck's
> mount-by-label/uuid code to deal with interesting cases such as
> kernels where devfs is configured, but not actually mounted (it
> changes what /proc/partitions exports). So I'm one of those who have
> never looked all that kindly on devfs, which shouldn't come as a
> surprise to most folks.

well I like devfs, in the sense that it is really easy to see what you can
use in /dev. Before i used devfs it could be quite difficult since there were
so much nodes and symlinks in /dev and many have cryptic names... and
sometimes the entries i needed simply were not there so i had to find the
right major/minor numbers to create them...

from a user point of view it is better to keep it because it could really
simplify a users life except ide should be just in discs as hdX and not as
/dev/ide/hostN/busX/targetY/lunZ/disc ...

>
> In any case, if there aren't all that many people using devfs, I can
> think of a really easy way in which we could simplify and clean up its
> API by slimming it down by 100%......

if the code is really that horrible, then maybe that is the best solution but
again i like the concept.

Rudmer
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/