This is where I agree. I do, however, think the consistant nature of the
devfs naming scheme will help vendors adapt to linux. As simple as
the /dev/sd shit is, it isn't similar to ANYTHING else. The devfs is more
like other standards than the /dev/sd scheme. IMHO, it needs help, as you
admit.
> Then we have three months to code and test it. That time frame is
> based on the projected release dates given by Oracle & Informix for
> their Linux products.
As much as Linux does not rely on commercial vendors porting software to
it, the benefit of this happening is immeaserable. Therefore, I agree
this is a MAJOR thing to think about, and NOW.
> Richard, I for one would rather live with thousands and thousands of
> inodes in /dev/ than live with the "ugly" naming scheme of dev_fs.
There is automagic "old name" compatibility, and you argument is false.
You may have read the FAQ, but when configured properly, NO changes have
to be made in /etc/fstab or anything in most cases.
> I readily agree that directory searches of a large /dev are slow
> but again I would rather live with a slow directory search than with
> the "ugly" naming scheme of dev_fs.
Again, your point is moot.
> We need to keep the "KISS" principle in mind. While the naming scheme
> of dev_fs may be logical it is not simple.
>
> /dev/sda, /dev/sda[1-15] is simple.
But ugly, and everyone admits it needs help. (At least mostly everyone)
> Richard, I have read your FAQ where the naming scheme for SCSI disks
> is described and it screams "ugly".
Correct != ugly!!!
-Shawn
<=========== America Held Hostage ===========>
Day 2022 for the poor and the middle class.
Day 2041 for the rich and the dead.
900 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