Unimportant when you can flame it about a bunch of at best vaguely
connected stuff? It's good to know that you're quite happy to flame
something without having investigated it properly.
> What is important is what companies and clients, looking
> to use Linux, think.
Who appointed you arbiter of what is important? Unless you can explain
why the diverse readers of linux-kernel should be interested in what
these companies think, then you are just flaming.
If you truly care about making Linux better, then either you write
code, you pay to have code written, or you motivate others to write
code. Are you doing any of these?
> There are two central issues for the companies
> and clients I have talked with.
>
> 1. >2GB files on Intel Hardware.
What does this remotely have to do with devfs? Maybe your flaming is
so spurious that you feel you need to pad your posts out?
If you do not know why the issue of large files is contraversial, then
go read the archives. If you come up with suggestions on how to
resolve the issues, I'm sure lots of people would be interested.
> 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.
Again, what does this have to do with devfs, except that devfs
introduces a naming scheme to _allow_ large numbers of SCSI devices.
If points are not aimed at devfs, them post them in a separate
article with a separate subject line.
> 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.
And do they intend to fund Linux development with some of the money
they save by using Linux?
> 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.
So the companies think that Linux is a cheap option, because some mug
will do the work for free, just to get them to use it?
> Companies want/desire/demand/need simple answers and dev_fs is not a
> simple answer.
It seems simple enough to me. It has the huge advantage over the
alternatives of actually existing as code, so that is works quite well
if you use it.
> They read the FAQ and run screaming away because of the
> naming scheme.
1. The devfs long naming scheme is certainly no worse than that of any
other Unix that tackles the problem.
2. It keeps the simple names everyone is familiar is.
3. I suspect Richard wrote that FAQ for "bleeding-edge" kernel users
who wanted to try his devfs patch out, *not* to soothe the fears of
the NT-using masses.
Why would a user of a distribution using devfs even care about the
naming scheme, unless they were fitting so many SCSI devices that they
had reason to care?
> It is clear that dev_fs will not be in Linux 2.2.
Yes, it seems unlikely that devs will be in 2.2. On the other hand, it
seems completely impossible that anything else solving the same
problems will be in 2.2.
> Companies are
> willing to work with a "standard" (whatever that is) Linux
> kernel. They do not want add on patches.
Surely, all other objections aside, this is a good reason to put devfs
in the kernel.
> There comments below also.
>
> [snip]
> >
> > > 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'm sure the code to add this to devfs would be fairly simple. When
you've written it, please send it to Richard.
> I would rather have files >2GB support on Intel Hardware.
Yes, Richard. Why doesn't the devfs patch have this? It must be crap.
I would rather go to sleep.
> [snip]
-- Dave Wragg
- 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