In <200004212053.e3LKrG505211@vindaloo.ras.ucalgary.ca> Richard Gooch (rgooch@ras.ucalgary.ca) wrote:
> willy@thepuffingroup.com writes:
>> On Fri, Apr 21, 2000 at 01:41:54PM -0600, Richard Gooch wrote:
>> > willy@thepuffingroup.com writes:
>> > > On Fri, Apr 21, 2000 at 11:00:26AM -0500, Stefan Monnier wrote:
>> > > > >>>>> "Keith" == Keith Owens <kaos@ocs.com.au> writes:
>> > > > > * Add ieee1394 directory, requested by Andreas Bombe.
>> > > >
>> > > > I know this has been mentioned before, but I'd like to reiterate
>> > > > my request for a way to just look in *every* subdirectory.
>> > > > I does not have to be the default, but it should be at least possible
>> > > > to get this behavior with some /etc/modules.conf editing.
>> > >
>> > > I'm not entirely sure why the modules are segregated into separate
>> > > directories anyway. The namespace collision already happens at
>> > > build time (when they're all symlinked into /usr/src/linux/modules)
>> > > and modprobe is invoked (by me anyway) with just the name of the
>> > > module, so why pretend it's not a flat namespace? Eschew
>> > > obfuscation.
>> >
>> > Because a flat directory is harder to view for the human. When I ask
>> > myself "do I have the ne2k-pci module", it's obvious to just look in
>> > the "net" directory.
>>
>> surely
>>
>> ls *ne2k*
>>
>> is not too hard for someone who wants to know the answer to that
>> question?
> So then I'll change the question to "what network drivers do I have".
> :-)
And HOW THIS will help you to find out if you have driver for
"Z8530 based HDLC cards" (scc.o) or "Packet Engines G-NIC PCI Gigabit
Ethernet adapter" (yellowfin.o) ? And WHERE my COM20020 arcnet driver at
all ??? I'm pretty sure I answered "compile as module" when was asked ...
-- cut --
$ ls /lib/modules/2.3.36/net
3c501.o
3c503.o
3c505.o
3c507.o
3c509.o
3c515.o
3c523.o
3c527.o
3c59x.o
6pack.o
82596.o
8390.o
ac3200.o
acenic.o
aironet4500_card.o
aironet4500_core.o
aironet4500_proc.o
arlan-proc.o
arlan.o
at1700.o
baycom_epp.o
baycom_par.o
baycom_ser_fdx.o
baycom_ser_hdx.o
bpqether.o
bsd_comp.o
cops.o
cs89x0.o
de4x5.o
de600.o
de620.o
depca.o
dgrs.o
dmascc.o
dmfe.o
dummy.o
e2100.o
eepro.o
eepro100.o
eexpress.o
epic100.o
eql.o
es3210.o
eth16i.o
ethertap.o
ewrk3.o
fmv18x.o
hdlcdrv.o
hp-plus.o
hp.o
hp100.o
ipddp.o
ircomm.o
irda.o
irda_deflate.o
irlan.o
lance.o
lne390.o
ltpc.o
mkiss.o
ne.o
ne2.o
ne2k-pci.o
ne3210.o
ni5010.o
ni52.o
ni65.o
pcnet32.o
plip.o
ppp_async.o
ppp_deflate.o
ppp_generic.o
ppp_synctty.o
rcpci.o
rrunner.o
rtl8139.o
sb1000.o
scc.o
seeq8005.o
sis900.o
sk98lin.o
sk_mca.o
slip.o
smc-mca.o
smc-ultra.o
smc-ultra32.o
smc9194.o
soundmodem.o
starfire.o
strip.o
tlan.o
tulip.o
via-rhine.o
wavelan.o
wd.o
yam.o
yellowfin.o
-- cut --
And now my IDE-SCSI emulation does not work. But where to look: in
/lib/modules/2.3.36/block or /lib/modules/2.3.36/scsi ? And why my IDE cd does
not have driver in /lib/modules/kernel/2.3.36/cdrom ??? Ahh.
It's in /lib/modules/2.3.36/block (.../ide in recent kernels).
Then IPX & AX.25. It's network protocols for sure and PPP is also
network protocol... Then WHY ipx.o is in /lib/modules/kernel/2.3.36/misc
while ppp*.o are in /lib/modules/kernel/2.3.36/net ??? Hmm. Is it really
helpfull for anyone ??? Sorry. This mess ALWAYS created more problems then
solutions for me...
>> > The subdirectories are a natural categorisation
>> > that makes life easier. It's not about pretending there is a
>> > hierarchical namespace.
>>
>> but it makes life somewhat more complex than necessary for the
>> kernel build scripts and for modutils.
> The kernel build scripts already have this "complexity" (which isn't
> really that much), and modutils do too. In fact, by just scanning all
> directories, modutils can be simplified. So we have nothing to lose.
Of course if I'll be able to find out list of supported networks cards with
ls it'll be usefull. But I can not: names of files do not resemble names of
supported chipsets in A LOT OF cases and not all drivers are in /net directory.
So I need to scan documentation anyway. What the benefit ?
> And at the end of the day, computers are supposed to make things
> easier for humans. I don't care if if takes me 5 milliseconds longer
> to compile and install my kernel modules, if it makes my life a bit
> easier.
In which way ?
> I can't see why we would change things in the direction of making it
> harder for humans, since we already have a reasonable system
> implemented. It's not like we need to invest days or weeks of coding
> effort.
For me `find /lib/modules/<version> modulename.o` always looked
longer then `find /lib/modules/<version> modulename.o` so I can not
see benefits.
-
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.tux.org/lkml/
This archive was generated by hypermail 2b29 : Sun Apr 23 2000 - 21:00:19 EST