lkml.org 
[lkml]   [1998]   [Aug]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: DEVFSv50 and /dev/fb? (or /dev/fb/? ???)
Hello Everyone;

I have not used dev_fs nor am I likely to, but that is unimportant. What
is important is what companies and clients, looking to use Linux, think.
There are two central issues for the companies and clients I have talked
with.

1. >2GB files on Intel Hardware.
2. Increasing the SCSI disk limit to something more like 32 or 64 disks,
up
from the current limit of 16 disks. The more the better.

The reasons for this are simple. Oracle & Informix have annouced support
for Linux. The companies want to recycle Intel hardware they currently
have
and get rid of HP-UX, Solaris, SCO Unix, etc which costs them dearly in
both
hardware maintainance and software maintainance.

The Linux Community has asked for this type of support and now we have.
The question is what are we going to do about it. By the end of the year
, assuming Oracle & Informix hold to their announced time schedules, we
need those two issues resolved. If we do not companies which are willing
to
give Linux a try will not.

Companies want/desire/demand/need simple answers and dev_fs is not a
simple
answer. They read the FAQ and run screaming away because of the naming
scheme.

It is clear that dev_fs will not be in Linux 2.2. Companies are willing
to
work with a "standard" (whatever that is) Linux kernel. They do not want
add
on patches.

There comments below also.

Richard Gooch wrote:
>
> Terry L. Ridder writes:
> > Richard Gooch wrote:
> > >
> > > Andrea Arcangeli writes:
> > > > On Tue, 4 Aug 1998, Shawn Leas wrote:
> > > >
> > > > >Specifically, what is ugly about it? Is it intrinsic in nature, or
> > > > >something fixable? Is the design flawed? Then how? Back up your
> > >
> > > I don't know how many times I need to repeat this: devfs is *not* just
> > > about working around the size of kdev_t or having a read-only or
> > > non-Unix root FS.
> > >
> > > The thing that really motivated me to start it was the horrible SCSI
> > > disc naming scheme (take out one ID and play musical chairs with your
> > > device names) and the fact that you have to have zillions of inodes to
> > > support all the possible SCSI discs you could have. Right now you need
> > > 256 inodes in /dev to ensure you can use and of the possible discs and
> > > partitions. Later as we support more SCSI discs, the number of inodes
> > > will have to be increased. Distributions will have to ship systems
> > > with /dev having thousands upon thousands of inodes. This is a
> > > joke. Apart from being incredibly ugly (having a huge /dev), having
> > > lots of inodes means that directory searches are quite slow.
> >
> > I am well aware of the current SCSI naming convention and what you
> > consider "ugly" I consider "simple beauty". I am pushing the SCSI
> > disk limit on one machine.
> >
> > Do I like the way /dev/sd? is rearranged when I pull a hard drive out
> > of the SCSI expansion box? Well no, but I have learned to live with
> > it for the time being. I have repeated posted stating that the Linux
> > Community has roughly 3 months to design an enhancement to increase
> > the SCSI drive limit, and deal with files > 2GB on Intel hardware.
>
> Fine, you don't like the new naming scheme. That's why the old names
> are still there. If you are deeply wedded to the old names, you are
> welcome to them. I'm not *forcing* you to use the new naming
> scheme. Go ahead and use the old names.

I agree you are not, but that is not at all stated in an explicit
manner.
Start from the premise that they want to keep the old style names,
what are the advantages that dev_fs gives them that the current /dev
does
not. You are scaring people away with detailed information about the new
naming scheme, but provide every little information about advantages
dev_fs
offers while keeping the old naming scheme.

>
> > 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.
>
> How about /dev/sd{a,b,c...} entries only for the discs you have? You
> can have that right now with devfs.

I would rather have /dev/sd[q-z] entries for the disks I want to add.
I would rather have files >2GB support on Intel Hardware.

>
> > 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, just use the old names: I didn't take tham away.

Than explain to what advantage dev_fs would give me other than I have
now? The FAQ describes how an end-users may have to create numerous
symlinks from /dev to /devfs.

>
> > 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.
>
> And you can keep using it.
>
> > > I've heard the suggestion that you use initrd to populate /dev
> > > automagically. IMHO that is simply silly. Firstly it takes time to
> > > create all those inodes (for devices you have). When you shut down you
> > > should probably remove those inodes. *This* is cleaner than devfs???
> > > If people want to automagically populate /dev from userspace, it
> > > requires information from the kernel (current boot logs do not provide
> > > sufficient information). Making the boot logs spit out information for
> > > every device file available is no good: the boot logs will be too
> > > cluttered. Creating a special /proc entry is better, but still
> > > requires hacking lots of drivers and then we have the inevitable
> > > problem where the format changes so the userspace tool has to be
> > > changed. Yuk, yuk, yuk.
> > >
> > > > I had to say that I never tried devfs and that it could be a very
> > > > confortable workaround but I can' t like it ;-). Probably I' ll try soon
> > > > though. I' m afraid to say this again and after the sure good work of
> > > > Richard...
> > >
> > > I would dearly like to hear practical solutions to *all* the issues I
> > > raise in the devfs FAQ. Every time this discussion comes up, I hear a
> > > selective subset of the issues which conveniently ignores all the
> > > other issues that devfs addresses. This then leaves some people with
> > > the feeling that "devfs is flawed, ugly and/or unnecessary", because
> > > they haven't thought about all the issues I raise in the FAQ.
> >
> > Richard, I have read your FAQ where the naming scheme for SCSI disks
> > is described and it screams "ugly".
>
> So ignore the new names and keep using the old names. Nothing in your
> message talks about devfs itself, you're only addressing the minor
> issue of naming, which is in fact not a problem.

Richard you missed the whole point. Companies and clients read the FAQ
the run away screaming. All they see are this really "ugly" naming
scheme.

>
> Regards,
>
> Richard....

--
Terry L. Ridder
Blue Danube Software (Blaue Donau Software)
"We do not write software, we compose it."

When the toast is burnt
and all the milk has turned
and Captain Crunch is waving farewell
when the Big One finds you
may this song remind you that they
don't serve breakfast in hell
==Breakfast==Newsboys

-
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

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