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/? ???)

Perhaps none to you, but it's very important to alot of us including me...

It preserves the old way so it doesn't bother you.. You dont even need to
compile it in.. It's nice, IT's clean and it doesn't affect you if you
dont use it.

Please stop complaining.

On Wed, 5 Aug 1998, Terry L Ridder wrote:

> Hello Everyone;
>
> Let put this is really simple terms:
>
> 1. Companies, clients, and I like the current naming conventions, and
> want
> to keep using the current naming conventions.
>
> 2. What advantage does dev_fs offer us over the present system?
> Understand
> that we do not care about thousands & thousands of inodes in /dev, we do
> not
> care about directory searches being slow. So given that what are the
> advantages?
>
>
> Shawn Leas wrote:
> >
> > On Tue, 4 Aug 1998, Terry L Ridder wrote:
> > > 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.
> >
> > Stephen, any comments?
> >
> > > 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 devfs's so-called ugly naming convention provides for this, and with a
> > minimum of device files to coordinate.
>
> I do not doubt what you are saying, but again the dev_fs FAQ conveys a
> totally
> different picture.
>
> <Begin Quote>
> Fail-safe Approach
> <subsection>
> ------------------
> Currently, not all device drivers in the kernel have been modified to
> use devfs. To allow booting of kernels with and without devfs support,
> you will want to copy the contents of /dev to /devfs. Then, remove
> entries in /dev which are now available in devfs and make them
> symbolic links to the entries in /devfs.
> Finally, edit your /etc/fstab or boot scripts so that devfs is mounted
> over /devfs on bootup. If devfs is supported, accessing devices
> supported by devfs will follow the symlinks to devfs. If devfs is not
> supported, accessing those same devices will follow the symlinks to
> /devfs which contains only old-style device nodes.
> Devices not supported by devfs will be found directly on /dev.
> Simple! You can also follow this principle for chroot gaols.
>
> Also note that if you leave CONFIG_DEVFS_ONLY to 'N' (the default),
> then your old-style (i.e. node-based) chroot /gaol/dev directories
> which you manually created will still work.
>
> I've provided a script called "mk-devlinks" in this directory which you
> can use to create symlinks in /dev and /devfs.
> <End Quote>
>
> The above is enough to scare many a company away. They read this and
> visions
> of HP-UX and Solaris begin running through their minds.
>
> >
> > > 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.
> >
> > Agreed. I work in a pretty big Oracle setup, and with the recent court
> > decisions regarding NDAs on Intel platforms such as the x86, Merced may
> > not be so proprietory for long. Oracle+Linux+Merced is a pretty damn nice
> > solution for price/performance, I'd say.
> >
> > > 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.
> >
> > DevFS steps us closer!
> >
> > > 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.
> >
> > Moot point, you are doing it again! Your FEAR(tm) is only because you've
> > not tried devfs. When you compile a kernel with it, you see options in
> > black and white, and their meaning is clear... And, BTW, the DEVFS is
> > about the most stable and accepted "EXPERIMENTAL" fs that I've seen.
>
> I have no desire to use dev_fs based on what I have read in the FAQ.
> It could be the neatest thing since sliced bread but I will not use it
> because of the manner in which it is presented in the FAQ. There is
> absolutely
> nothing in the FAQ that jumps out and grabs me and says:
>
> "If you want the old style naming convention that is fine, here are
> the other advantages that you will have by using dev_fs."
>
> I am not doing it again. I am telling you that companies do not like
> the naming scheme that is presented in the FAQ. If they wanted that type
> of naming scheme they would stay the HP-UX and Solaris. They want
> simple.
> What they currently see in /dev for SCSI disks is what they want, they
> just
> want more.
>
> >
> > [*] /dev filesystem support (EXPERIMENTAL)
> > [*] Disable major&minor support for devfs-capable drivers
> > [ ] Disable old device names
> > [ ] Disable old tty names
> > [ ] Enable real tty compatibility devices
> > [*] Automatically mount at boot
> > [ ] Debug devfs
> > [*] Boot-time options
>
> Companies and clients do not care about this type of information.
> What they care about is that dev_fs looks like HP-UX and Solaris
> which is exactly what they are trying to get away from.
>
> >
> > -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.
> > <============================================>
>
> --
> 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
>


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