> On Fri, 7 Aug 1998, Richard Gooch wrote:
>
> > I do think that major&minor numbers are conceptually a dirty hack.
>
> But we have to keep them because they are embedded fairly deep
> in the standards and the existing application code base.
We all agree here, POSIX does too. We should try to at least escape their
boundries, while using them at the same time.
> So don't do it? Use sub-directories. It isn't that big a deal.
Hmm, calculate all possible SCSI disk configurations and then give me what
you think would be a good unconfusing layout.
How would you know what device nodes you need to have there other than by
having some userland utility? You are dodging other questions.
> There is no reason scsidev could not be extended to handle things
> other than SCSI. I'll even volunteer to do it if required. However,
> I'm not aware of a USB driver for Linux yet and I don't see an
> awful lot of USB devices on the market yet.
Ugh... I think that there is, but scsidev is not a bad thing. Don't get
me wrong!!!
> The one thing a kernel space solution like devfs has over a user
> space solution like scsidev is the ability to handle a moving root
> filesystem. Is it worth the kernel bloat though? I mean, *I* want
> my root fs to be as stable as possible. If it moves my hardware
> planning is broken and needs fixing - not Linux.
It's small, it's not bloat.
> Hot plugging has been with us for *ages*. Remember PCMCIA? All you
> need to do is to kick off a "set me up script" when the driver
> detects a device change. Or you can trigger it manually. Or even
> run a "check and set" from cron :-).
Ugly hack.
> > OK, this is separate from the devfs concept. I've already stated
> > several times that I could add persistence to devfs. I could either
> > write things to a block device or peek through to the mounted-over
> > inodes.
> > Would such a change make you feel better?
>
> It sounds hideous :-). It's a hack to correct the fact that the
> nodes are stored in a virtual filesystem when they should have
> been stored on a physical filesystem to start with.
See above comment, that's an uglier hack. Richard has stated as you so
conveniently ignore, that he could add persistance.
> > I think that the extra layer between device nodes and device drivers
> > is an ugly hack. I see the extra level of indirection as unnecessary
> > and adding some (small, but avoidable) performance overhead.
>
> Huh???
If you don't understand, don't try to ask.
> They show devfs provides one solution to the claimed problems. The
> arguments are because (a) there are other lighter weight solutions
> with less kernel impact like scsidev which do the vast majority
> of what devfs does, and (b) not everyone agrees that the claimed
> problems actually exist and they are not documented.
They are singular bandaids to symptoms. Not a solution to a fundamental
problem.
-Shawn
<=========== America Held Hostage ===========>
Day 2025 for the poor and the middle class.
Day 2044 for the rich and the dead.
897 days remaining in the Raw Deal.
<============================================>
-
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.altern.org/andrebalsa/doc/lkml-faq.html