Re: KLD naming
well you're about to get your first test we are releasing the netgrpah code in full production form tonigh (if the version we've put together for release passes all tests tonight) The whole thing installs as KLD modules (or linked in of course) our present names are all predicated with ng_ hence ng_socket ng_rfc1490, ng_frame_relay etc the base module is 'netgraph'. now what would you suggest? we can still cahnge it before we release and no-body knows any better but after is always harder to change than beefore.. julian On Wed, 20 Jan 1999, Mike Smith wrote: On Wed, Jan 20, 1999 at 07:19:15PM -0800, David O'Brien wrote: [..] etc? This is what the original poster suggested, and nobody has really given a good response what is wrong with the grouping being expressed in the modules' name. Mike Smith and Andrzej Bialecki have given good reasons why *not* to go to a subdirectory structure. What would you name a network stack? For example: net_mpls_tdp.ko net_mpls_ldp.ko net_mpls_core.ko or net_h323v2_yada.ko net_h323v2_yadayada.ko net_h323v2_barf.ko or codec_g711.ko codec_g7231a.ko codec_g729.ko Is that acceptable? Anyone have better ideas? I guess it depends on how fancy we want to get. Here are some examples that I've been rolling around; some are fanciful, some practical) dev_generic device (eg. dev_sio) bus_bus support (eg. bus_pci) netif_ network interface (eg. netif_ed) netproto_ network protocol (eg. netproto_arp) netdomain_ network domain (eg. netdomain_ip) vfs_VFS layer (eg. vfs_nfs) kern_ kernel infrastructure (eg. kern_vfs) syscall_loadable system calls (eg. syscall_sendfile) I don't think we want to make the mistake of being too specific about what pigeonhole something falls into. In many cases, we might want new categories when a new case arises, eg. for USB we might have: bus_usb.ko usb_hub.ko usb_mouse.ko usb_keyboard.ko usb_disk.ko usb_scanner.ko ... There's no ambiguity here, the names are simple and convey a direct set of relationships. Your examples (except the first) do a pretty good job of the same thing. -- \\ Sometimes you're ahead, \\ Mike Smith \\ sometimes you're behind. \\ m...@smith.net.au \\ The race is long, and in the \\ msm...@freebsd.org \\ end it's only with yourself. \\ msm...@cdrom.com To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: KLD naming
well you're about to get your first test we are releasing the netgrpah code in full production form tonigh (if the version we've put together for release passes all tests tonight) The whole thing installs as KLD modules (or linked in of course) our present names are all predicated with ng_ hence ng_socket ng_rfc1490, ng_frame_relay etc the base module is 'netgraph'. now what would you suggest? we can still cahnge it before we release and no-body knows any better but after is always harder to change than beefore.. Hmm. Where does netgraph fit in? From your earlier commits, I presume it's a domain, so I would suggest: netdomain_netgraph.ko netgraph_rfc1490.ko netgraph_framerelay.ko ... ie. don't be afraid to be verbose. I'd certainly say no to a two-letter abbreviation. julian On Wed, 20 Jan 1999, Mike Smith wrote: On Wed, Jan 20, 1999 at 07:19:15PM -0800, David O'Brien wrote: [..] etc? This is what the original poster suggested, and nobody has really given a good response what is wrong with the grouping being expressed in the modules' name. Mike Smith and Andrzej Bialecki have given good reasons why *not* to go to a subdirectory structure. What would you name a network stack? For example: net_mpls_tdp.ko net_mpls_ldp.ko net_mpls_core.ko or net_h323v2_yada.ko net_h323v2_yadayada.ko net_h323v2_barf.ko or codec_g711.ko codec_g7231a.ko codec_g729.ko Is that acceptable? Anyone have better ideas? I guess it depends on how fancy we want to get. Here are some examples that I've been rolling around; some are fanciful, some practical) dev_generic device (eg. dev_sio) bus_bus support (eg. bus_pci) netif_ network interface (eg. netif_ed) netproto_ network protocol (eg. netproto_arp) netdomain_ network domain (eg. netdomain_ip) vfs_VFS layer (eg. vfs_nfs) kern_ kernel infrastructure (eg. kern_vfs) syscall_loadable system calls (eg. syscall_sendfile) I don't think we want to make the mistake of being too specific about what pigeonhole something falls into. In many cases, we might want new categories when a new case arises, eg. for USB we might have: bus_usb.ko usb_hub.ko usb_mouse.ko usb_keyboard.ko usb_disk.ko usb_scanner.ko ... There's no ambiguity here, the names are simple and convey a direct set of relationships. Your examples (except the first) do a pretty good job of the same thing. -- \\ Sometimes you're ahead, \\ Mike Smith \\ sometimes you're behind. \\ m...@smith.net.au \\ The race is long, and in the \\ msm...@freebsd.org \\ end it's only with yourself. \\ msm...@cdrom.com To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message -- \\ Sometimes you're ahead, \\ Mike Smith \\ sometimes you're behind. \\ m...@smith.net.au \\ The race is long, and in the \\ msm...@freebsd.org \\ end it's only with yourself. \\ msm...@cdrom.com To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: KLD naming
On Wed, 20 Jan 1999, Mike Smith wrote: I guess it depends on how fancy we want to get. Here are some examples that I've been rolling around; some are fanciful, some practical) dev_generic device (eg. dev_sio) bus_bus support (eg. bus_pci) netif_ network interface (eg. netif_ed) netproto_ network protocol (eg. netproto_arp) netdomain_ network domain (eg. netdomain_ip) vfs_VFS layer (eg. vfs_nfs) kern_ kernel infrastructure (eg. kern_vfs) syscall_loadable system calls (eg. syscall_sendfile) I don't think we want to make the mistake of being too specific about what pigeonhole something falls into. In many cases, we might want new categories when a new case arises, eg. for USB we might have: bus_usb.ko usb_hub.ko usb_mouse.ko usb_keyboard.ko usb_disk.ko usb_scanner.ko ... There's no ambiguity here, the names are simple and convey a direct set of relationships. Your examples (except the first) do a pretty good job of the same thing. This is good. As far as I'm concerned, we should go with this. -- Doug Rabson Mail: d...@nlsystems.com Nonlinear Systems Ltd. Phone: +44 181 442 9037 To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
RE: KLD naming
-Original Message- From: Julian Elischer [mailto:jul...@whistle.com] Sent: Thursday, January 21, 1999 7:58 AM To: Mike Smith Cc: Christian Kuhtz; David O'Brien; curr...@freebsd.org Subject: Re: KLD naming well you're about to get your first test we are releasing the netgrpah code in full production form tonigh (if the version we've put together for release passes all tests tonight) The whole thing installs as KLD modules (or linked in of course) our present names are all predicated with ng_ hence ng_socket ng_rfc1490, ng_frame_relay etc the base module is 'netgraph'. now what would you suggest? we can still cahnge it before we release and no-body knows any better but after is always harder to change than beefore.. Why not have a third party identifier on the front, e.g. whistle_ng_rfc1490 You can determine your own naming scheme then and if we make this standard then it will ensure that third party supplied modules don't result in name space conflicts. It's perfectly feasible in the future that different companies might produce competing modules for subsystems, sound for example, so we might as well deal with this possibility now. Makes it easier to identify the source of the modules as well. Perhaps we should adopt a FreeBSD prefix on core modules so you can see from ls what's part of the OS and what's been added in from elsewhere. Although I'm in favour of this naming scheme over directories you can reach the point where the names are holding too much metainformation that really should be directory structure. There wouldn't be need for directories at all if you put the structure in the filename :-) Paul. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: KLD naming
On Thu, Jan 21, 1999 at 09:34:28AM +, Doug Rabson wrote: On Wed, 20 Jan 1999, Mike Smith wrote: I guess it depends on how fancy we want to get. Here are some examples that I've been rolling around; some are fanciful, some practical) dev_generic device (eg. dev_sio) bus_bus support (eg. bus_pci) netif_ network interface (eg. netif_ed) netproto_ network protocol (eg. netproto_arp) netdomain_ network domain (eg. netdomain_ip) How is the difference between netproto netdomain defined? I'm running into a case where I can easily turn the stack upside down (say, running frame-relay over IP over MPLS in an IP tunnel over PPP -- that's almost working actually). It sounds like netdomain is somehow higher up in the stack than netproto.. even though they're all protocols. Comments? Cheers, Chris -- Logic is a little bird, sitting in a tree; that smells *awful*. -- /usr/bin/fortune [Disclaimer: I speak for myself and my views are my own and not in any way to be construed as the views of BellSouth Corporation. ] To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
RE: KLD naming
On Thu, 21 Jan 1999 p...@originative.co.uk wrote: Why not have a third party identifier on the front, e.g. whistle_ng_rfc1490 You can determine your own naming scheme then and if we make this standard then it will ensure that third party supplied modules don't result in name space conflicts. It's perfectly feasible in the future that different companies might produce competing modules for subsystems, sound for example, so we might as well deal with this possibility now. Makes it easier to identify the source of the modules as well. Perhaps we should adopt a FreeBSD prefix on core modules so you can see from ls what's part of the OS and what's been added in from elsewhere. Although I'm in favour of this naming scheme over directories you can reach the point where the names are holding too much metainformation that really should be directory structure. There wouldn't be need for directories at all if you put the structure in the filename :-) Well whistle is giving htis away so we don'tthink it should be whistle_xxx any more than the kernel should be UCB/... It occur to me that eventually every single device driver will be a KLD an also a lot of other things besides... there are going to be a LOT of files in /modules Paul. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: KLD naming
On Thu, 21 Jan 1999, Christian Kuhtz wrote: On Thu, Jan 21, 1999 at 09:34:28AM +, Doug Rabson wrote: On Wed, 20 Jan 1999, Mike Smith wrote: I guess it depends on how fancy we want to get. Here are some examples that I've been rolling around; some are fanciful, some practical) dev_generic device (eg. dev_sio) bus_bus support (eg. bus_pci) netif_ network interface (eg. netif_ed) netproto_ network protocol (eg. netproto_arp) netdomain_ network domain (eg. netdomain_ip) How is the difference between netproto netdomain defined? I'm running into a case where I can easily turn the stack upside down (say, running frame-relay over IP over MPLS in an IP tunnel over PPP -- that's almost working actually). It sounds like netdomain is somehow higher up in the stack than netproto.. even though they're all protocols. Comments? Cheers, Chris -- Logic is a little bird, sitting in a tree; that smells *awful*. -- /usr/bin/fortune [Disclaimer: I speak for myself and my views are my own and not in any way to be construed as the views of BellSouth Corporation. ] To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
RE: KLD naming
-Original Message- From: Julian Elischer [mailto:jul...@whistle.com] Sent: Thursday, January 21, 1999 5:39 PM To: p...@originative.co.uk Cc: m...@smith.net.au; c...@adsu.bellsouth.com; obr...@nuxi.com; curr...@freebsd.org Subject: RE: KLD naming Well whistle is giving htis away so we don'tthink it should be whistle_xxx any more than the kernel should be UCB/... It occur to me that eventually every single device driver will be a KLD an also a lot of other things besides... there are going to be a LOT of files in /modules Ok, in this case maybe it doesn't apply but in general we should determine what the guidelines for third party module developers should be to avoid namespace clashes. I though a FreeBSD prefix for modules shipped as part of FreeBSD would be useful to list all those modules that are *not* third party supplied when you've got a directory full of the things. Paul. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: KLD naming
Well whistle is giving htis away so we don'tthink it should be whistle_xxx any more than the kernel should be UCB/... It occur to me that eventually every single device driver will be a KLD an also a lot of other things besides... there are going to be a LOT of files in /modules Ok, in this case maybe it doesn't apply but in general we should determine what the guidelines for third party module developers should be to avoid namespace clashes. I though a FreeBSD prefix for modules shipped as part of FreeBSD would be useful to list all those modules that are *not* third party supplied when you've got a directory full of the things. I've thought about this, and I think it would be a very bad idea. We want to keep this *simple*. In the case of, eg. OSS, one might expect: dev_oss.ko oss_yamaha.ko oss_sb16.ko ... There's no need to add extra crap just to identify the vendor. It doesn't serve any really useful purpose - we will have metainformation elsewhere that can be used to link modules comprising a product together - there's no need to duplicate it in the filename. -- \\ Sometimes you're ahead, \\ Mike Smith \\ sometimes you're behind. \\ m...@smith.net.au \\ The race is long, and in the \\ msm...@freebsd.org \\ end it's only with yourself. \\ msm...@cdrom.com To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
kld meta info (Re: KLD naming)
Is there meta information in a .ko file? That way you could do a kldinfo to find out where to go for more info, etc. On Thu, Jan 21, 1999 at 11:13:49AM -0800, Mike Smith wrote: I've thought about this, and I think it would be a very bad idea. We want to keep this *simple*. In the case of, eg. OSS, one might expect: dev_oss.ko oss_yamaha.ko oss_sb16.ko ... There's no need to add extra crap just to identify the vendor. It doesn't serve any really useful purpose - we will have metainformation elsewhere that can be used to link modules comprising a product together - there's no need to duplicate it in the filename. -- Logic is a little bird, sitting in a tree; that smells *awful*. -- /usr/bin/fortune [Disclaimer: I speak for myself and my views are my own and not in any way to be construed as the views of BellSouth Corporation. ] To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: kld meta info (Re: KLD naming)
Is there meta information in a .ko file? That way you could do a kldinfo to find out where to go for more info, etc. There's not time to standardise this, so I would say that 3.x .ko files won't have metainformation internally, no. Certainly 4.x .ko files will carry a lot more metainformation with them, and that may include this, yes. On Thu, Jan 21, 1999 at 11:13:49AM -0800, Mike Smith wrote: I've thought about this, and I think it would be a very bad idea. We want to keep this *simple*. In the case of, eg. OSS, one might expect: dev_oss.ko oss_yamaha.ko oss_sb16.ko ... There's no need to add extra crap just to identify the vendor. It doesn't serve any really useful purpose - we will have metainformation elsewhere that can be used to link modules comprising a product together - there's no need to duplicate it in the filename. -- Logic is a little bird, sitting in a tree; that smells *awful*. -- /usr/bin/fortune [Disclaimer: I speak for myself and my views are my own and not in any way to be construed as the views of BellSouth Corporation. ] -- \\ Sometimes you're ahead, \\ Mike Smith \\ sometimes you're behind. \\ m...@smith.net.au \\ The race is long, and in the \\ msm...@freebsd.org \\ end it's only with yourself. \\ msm...@cdrom.com To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: KLD naming
I've taken this off list. I'm not sure we're quite addressing the same issue. No, I think we were at angles for a bit here. But I do believe that this is something work copying to people on the list, as you do raise a very good point. I hope this was on -current. 8) I've thought about this, and I think it would be a very bad idea. We want to keep this *simple*. In the case of, eg. OSS, one might expect: dev_oss.ko oss_yamaha.ko oss_sb16.ko ... There's no need to add extra crap just to identify the vendor. It doesn't serve any really useful purpose - we will have metainformation elsewhere that can be used to link modules comprising a product together - there's no need to duplicate it in the filename. It's not a question, primarily, of being able to identify the vendor from the filename, it's more the case of different vendors not both choosing the *same* filename thereby making it very difficult to install them both at the same time. I'm saying primarily since if we do have a vendor prefix in the filename it would make it easy to see where a module came from but that is not my main motivation for suggesting it. I'm proposing that the guidleline be that anyone wishing to publish their own modules (i.e. not contribute them to the FreeBSD source base) should effectively create their own namespace by prefixing the filename with a vendor code. This would make clashes a lot less likely and if necessary a registry of vendor codes would have to be made available. I can't see how you can avoid namespace clashes otherwise. Third party developers aren't likely to communicate with each other to ensure uniqueness so it's better that the naming convention provide a mechanism for such parties to ensure that the filenames they choose don't clash with other people's modules. Ah, understood. I'd be inclined to use a suffix, so that our prefix-based classification scheme still worked, eg. dev_ahc_Adaptec.ko kern_descrypt_RSA.ko etc. It'd be very irritating to pop a floppy in the machine that you got from some vendor, run install and then find that some important module had been overwritten from the vendor disk, or that the install failed because it couldn't copy over all the modules. Understood now, yes. -- \\ Sometimes you're ahead, \\ Mike Smith \\ sometimes you're behind. \\ m...@smith.net.au \\ The race is long, and in the \\ msm...@freebsd.org \\ end it's only with yourself. \\ msm...@cdrom.com To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
RE: KLD naming
-Original Message- From: Mike Smith [mailto:m...@smith.net.au] Sent: Thursday, January 21, 1999 8:25 PM To: p...@originative.co.uk Cc: curr...@freebsd.org Subject: Re: KLD naming ... Ah, understood. I'd be inclined to use a suffix, so that our prefix-based classification scheme still worked, eg. dev_ahc_Adaptec.ko kern_descrypt_RSA.ko etc. Hmm, wouldn't this impose our kernel structure onto modules? This might not be desirable for external developers, they may just want to provide a single module rather than split the product into submodules that fit our categories. Why not allow SafeCo_firewall.ko rather than netif_foo_SafeCo.ko netproto_bar_SafeCo.ko etc. Paul. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
RE: KLD naming
-Original Message- From: Archie Cobbs [mailto:arc...@whistle.com] Sent: Wednesday, January 20, 1999 6:13 AM To: d...@nlsystems.com Cc: gelde...@mediaport.org; curr...@freebsd.org Subject: Re: KLD naming Doug Rabson writes: Might it be a good idea to choose a consistent naming scheme for the modules? I'd think so because it would help blind loading at the boot prompt. If you choose names it the following format: type_name saver_warp saver_daemon the modules of one type will sort together in a directory listing. This is a change that will make FreeBSD more user friendly I think. When I first started writing KLD, I had a vague notion that there would be a simple directory structure under /modules, e.g.: /modules pci/ ncr.ko ... isa/ if_ed.ko ... ... I like this idea (subdirectories) better.. it will last longer :-) Witness the explosion of the ports tree. You should then be able to load a module isa/if_ed.ko etc and have it work (no leading slash). I don't think subdirectories based on bus type is a good idea, it doesn't really fit the granularity we're probably heading towards. Some thinks don't really fit at all, filesystems, screen savers etc and even for drivers we're heading towards less bus specific devices so an ethernet driver, say, would be the same for any bus, only the startup code would be different and possibly(probably) in a different module. A functional structure is probably better /modules /devices /ethernet /storage /display /network /filesystems /screensavers etc. Not a specific proposal for actual directories but perhaps a better direction. I think we should start thinking more in terms of function, rather than bus, in a lot of what we do with devices as we abstract out the bus code more effectively. Paul. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: KLD naming
From: Archie Cobbs arc...@whistle.com Doug Rabson writes: Might it be a good idea to choose a consistent naming scheme for the modules? I'd think so because it would help blind loading at the boot prompt. If you choose names it the following format: type_name saver_warp saver_daemon the modules of one type will sort together in a directory listing. This is a change that will make FreeBSD more user friendly I think. When I first started writing KLD, I had a vague notion that there would be a simple directory structure under /modules, e.g.: /modules pci/ ncr.ko ... isa/ if_ed.ko ... ... I like this idea (subdirectories) better.. it will last longer :-) Witness the explosion of the ports tree. I witnessed. But I don't think we will be heading that way. Even if you have 40 modules in each category, this ought to work (ls saver*). It will work because we prefix every driver with it's type so they sort together. This would have worked for the ports tree as well. Another advantage of the flat model is that it's way easier to browse. IMHO it's a real pain to have descend into subdirectories, only to find out that you want to look in another one. Cheers, Jeroen -- Jeroen C. van Gelderen -- gelde...@mediaport.org -- 0x46D8D3C8 -- [8-D}~= To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: KLD naming
When I first started writing KLD, I had a vague notion that there would be a simple directory structure under /modules, e.g.: /modules pci/ ncr.ko ... isa/ if_ed.ko ... ... I like this idea (subdirectories) better.. it will last longer :-) It's a really bad idea, because it requires you to classify things. It also makes it much harder to administer. In addition, classifications are bad (witness the need to reorganise the kernel source tree). You should then be able to load a module isa/if_ed.ko etc and have it work (no leading slash). And here is a good example. Why would you want to put if_ed in the ISA category when it can be attached to both the PCI and ISA busses? In fact, we can implement this (maybe it already works) before coming to a final decision on what the actual layout should be. A single directory holding module files. -- \\ Sometimes you're ahead, \\ Mike Smith \\ sometimes you're behind. \\ m...@smith.net.au \\ The race is long, and in the \\ msm...@freebsd.org \\ end it's only with yourself. \\ msm...@cdrom.com To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: KLD naming
Mike Smith writes: When I first started writing KLD, I had a vague notion that there would be a simple directory structure under /modules, e.g.: /modules pci/ ncr.ko ... isa/ if_ed.ko ... ... I like this idea (subdirectories) better.. it will last longer :-) It's a really bad idea, because it requires you to classify things. It also makes it much harder to administer. In addition, classifications are bad (witness the need to reorganise the kernel source tree). You should then be able to load a module isa/if_ed.ko etc and have it work (no leading slash). And here is a good example. Why would you want to put if_ed in the ISA category when it can be attached to both the PCI and ISA busses? I don't care how you classify it.. of course the isa category is wrong. I was just pointing out that having things in subdirectories is better than having a zillion files piled into a single directory. are bad (witness the need to reorganise the kernel source tree). Maybe I'm just an optimist.. but if we have already solved (through various incarnations) how to classify the kernel source, then we can pretty much inherit this same classification scheme for the modules. After all, they are all *kernel* modules, right? A single directory holding module files. Blech :-) -Archie ___ Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: KLD naming
[KLD module file locations] I was just pointing out that having things in subdirectories is better than having a zillion files piled into a single directory. I'm torn between agreeing that it's tidier and disagreeing on the grounds that it's much more of a pain to administer. Where is that damnned module? Why am I loading a stale version of saver_foo?, etc. As a rule when I'm thinking about KLDs I look at the way that MacOS manages inits/extensions. That's a model that's survived over a decade of use by generally fairly clueless users, and hasn't completely irritated the smarter ones either. are bad (witness the need to reorganise the kernel source tree). Maybe I'm just an optimist.. but if we have already solved (through various incarnations) how to classify the kernel source, then we can pretty much inherit this same classification scheme for the modules. The fact that we're trying to reorganise the kernel sources right now tends to indicate to me that we haven't solved this at all. A single directory holding module files. Blech :-) Put aside the aesthetics for a moment, and try to raise some real, practical objections. I'm continually battling my own temptation to make the whole module thing more complex, but if you've got really good reasons that can justify the extra complexity everywhere I'm still open to suggestions. -- \\ Sometimes you're ahead, \\ Mike Smith \\ sometimes you're behind. \\ m...@smith.net.au \\ The race is long, and in the \\ msm...@freebsd.org \\ end it's only with yourself. \\ msm...@cdrom.com To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: KLD naming
On Wed, 20 Jan 1999, Archie Cobbs wrote: I like this idea (subdirectories) better.. it will last longer :-) It's a really bad idea, because it requires you to classify things. It also makes it much harder to administer. In addition, classifications are bad (witness the need to reorganise the kernel source tree). You should then be able to load a module isa/if_ed.ko etc and have it work (no leading slash). And here is a good example. Why would you want to put if_ed in the ISA category when it can be attached to both the PCI and ISA busses? I don't care how you classify it.. of course the isa category is wrong. I was just pointing out that having things in subdirectories is better than having a zillion files piled into a single directory. Not always. Consider a case when all modules are on a slow media (such as a floppy or zipfs) - then putting things in subdirs adds quite significant overhead to load/ls/search due to pathname lookups. Andrzej Bialecki ++---++ - ab...@nask.pl ||PicoBSD|| FreeBSD in your pocket? Go and see: Research Academic |+---+| Small Embedded FreeBSD Network in Poland | |TT~~~| |http://www.freebsd.org/~picobsd/ ~-+==---+-+ - To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: KLD naming
Mike Smith writes: A single directory holding module files. Blech :-) Put aside the aesthetics for a moment, and try to raise some real, practical objections. I'm continually battling my own temptation to make the whole module thing more complex, but if you've got really good reasons that can justify the extra complexity everywhere I'm still open to suggestions. You've got a good point, I don't have any really good reasons, other than trying to be 'organized'. I guess if it looks like the number of files is getting out of hand, then at that time we can say I told you so! and then fix the problem. Solving problems on-demand rather than preemptively is more efficient I suppose.. :-) -Archie ___ Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: KLD naming
On Wed, Jan 20, 1999 at 03:36:14PM -0800, Mike Smith wrote: [KLD module file locations] I was just pointing out that having things in subdirectories is better than having a zillion files piled into a single directory. I'm torn between agreeing that it's tidier and disagreeing on the grounds that it's much more of a pain to administer. Where is that damnned module? Why am I loading a stale version of saver_foo?, etc. Perhaps something more along the lines of: /modules- empty, except for directories /console- console related modules blank_saver.ko, daemon_saver.ko, fade_saver.ko, green_saver.ko, logo_saver.ko, rain_saver.ko, snake_saver.ko, star_saver.ko, vesa.ko, warp_saver.ko /devices- device drivers. joy.ko /emulation - like linux, fpu, etc... fpu.ko, gnufpu.ko, ibcs2.ko, ibcs2_coff.ko, linux.ko /fs - filesystem related modules atapi.ko, ccd.ko, cd9660.ko, coda.ko, fdesc.ko, kernfs.ko, mfs.ko, msdos.ko, nfs.ko, null.ko, portal.ko, procfs.ko, umap.ko, union.ko, vinum.ko /net- network related modules. if_disc.ko, if_ppp.ko, if_sl.ko, if_tun.ko, ipfw.ko I think this takes care of everything currently in /modules. -- Zach Heilig z...@uffdaonline.net / Zach Heilig z...@gaffaneys.com To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: KLD naming
Perhaps something more along the lines of: /modules- empty, except for directories /console- console related modules blank_saver.ko, daemon_saver.ko, fade_saver.ko, green_saver.ko, Gross. What is wrong with: saver_*.ko device_*.ko linux_*.ko fs_*.ko if_*.ko etc? This is what the original poster suggested, and nobody has really given a good response what is wrong with the grouping being expressed in the modules' name. Mike Smith and Andrzej Bialecki have given good reasons why *not* to go to a subdirectory structure. -- -- David(obr...@nuxi.com -or- obr...@freebsd.org) To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: KLD naming
Why not just follow the directory structure under /sys? Afterall, we are talking about kernel stuff here. On Wed, Jan 20, 1999 at 10:58:13AM -, p...@originative.co.uk wrote: [..] I don't think subdirectories based on bus type is a good idea, it doesn't really fit the granularity we're probably heading towards. Some thinks don't really fit at all, filesystems, screen savers etc and even for drivers we're heading towards less bus specific devices so an ethernet driver, say, would be the same for any bus, only the startup code would be different and possibly(probably) in a different module. A functional structure is probably better /modules /devices /ethernet /storage /display /network /filesystems /screensavers etc. Not a specific proposal for actual directories but perhaps a better direction. I think we should start thinking more in terms of function, rather than bus, in a lot of what we do with devices as we abstract out the bus code more effectively. Paul. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message -- Logic is a little bird, sitting in a tree; that smells *awful*. -- /usr/bin/fortune [Disclaimer: I speak for myself and my views are my own and not in any way to be construed as the views of BellSouth Corporation. ] To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: KLD naming
On Wed, Jan 20, 1999 at 07:19:15PM -0800, David O'Brien wrote: [..] etc? This is what the original poster suggested, and nobody has really given a good response what is wrong with the grouping being expressed in the modules' name. Mike Smith and Andrzej Bialecki have given good reasons why *not* to go to a subdirectory structure. What would you name a network stack? For example: net_mpls_tdp.ko net_mpls_ldp.ko net_mpls_core.ko or net_h323v2_yada.ko net_h323v2_yadayada.ko net_h323v2_barf.ko or codec_g711.ko codec_g7231a.ko codec_g729.ko Is that acceptable? Anyone have better ideas? Cheers, Chris -- Logic is a little bird, sitting in a tree; that smells *awful*. -- /usr/bin/fortune [Disclaimer: I speak for myself and my views are my own and not in any way to be construed as the views of BellSouth Corporation. ] To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: KLD naming
On Wed, 20 Jan 1999, Mike Smith wrote: I was just pointing out that having things in subdirectories is better than having a zillion files piled into a single directory. I'm torn between agreeing that it's tidier and disagreeing on the grounds that it's much more of a pain to administer. Where is that damnned module? Why am I loading a stale version of saver_foo?, etc. Putting the source code in different directories is not equivilent to putting the modules in different directories, needless to say. :-) As such, I think having a structured source tree is really nice, but the simplicity of modules in a single directory in the style of MacOS extensions as you discuss has appeal (and means that users don't have to try and reproduce a directory hierarchy for binary-only modules they get somewhere). On the other hand, this still requires moderation in namespace use for modules. Robert N Watson rob...@fledge.watson.org http://www.watson.org/~robert/ PGP key fingerprint: 03 01 DD 8E 15 67 48 73 25 6D 10 FC EC 68 C1 1C Carnegie Mellon Universityhttp://www.cmu.edu/ TIS Labs at Network Associates, Inc. http://www.tis.com/ SafePort Network Services http://www.safeport.com/ To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: KLD naming
On Wed, Jan 20, 1999 at 07:19:15PM -0800, David O'Brien wrote: [..] etc? This is what the original poster suggested, and nobody has really given a good response what is wrong with the grouping being expressed in the modules' name. Mike Smith and Andrzej Bialecki have given good reasons why *not* to go to a subdirectory structure. What would you name a network stack? For example: net_mpls_tdp.ko net_mpls_ldp.ko net_mpls_core.ko or net_h323v2_yada.ko net_h323v2_yadayada.ko net_h323v2_barf.ko or codec_g711.ko codec_g7231a.ko codec_g729.ko Is that acceptable? Anyone have better ideas? I guess it depends on how fancy we want to get. Here are some examples that I've been rolling around; some are fanciful, some practical) dev_generic device (eg. dev_sio) bus_bus support (eg. bus_pci) netif_ network interface (eg. netif_ed) netproto_ network protocol (eg. netproto_arp) netdomain_ network domain (eg. netdomain_ip) vfs_VFS layer (eg. vfs_nfs) kern_ kernel infrastructure (eg. kern_vfs) syscall_loadable system calls (eg. syscall_sendfile) I don't think we want to make the mistake of being too specific about what pigeonhole something falls into. In many cases, we might want new categories when a new case arises, eg. for USB we might have: bus_usb.ko usb_hub.ko usb_mouse.ko usb_keyboard.ko usb_disk.ko usb_scanner.ko ... There's no ambiguity here, the names are simple and convey a direct set of relationships. Your examples (except the first) do a pretty good job of the same thing. -- \\ Sometimes you're ahead, \\ Mike Smith \\ sometimes you're behind. \\ m...@smith.net.au \\ The race is long, and in the \\ msm...@freebsd.org \\ end it's only with yourself. \\ msm...@cdrom.com To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: KLD naming
I guess it depends on how fancy we want to get. Here are some examples that I've been rolling around; some are fanciful, some practical) dev_generic device (eg. dev_sio) bus_bus support (eg. bus_pci) netif_ network interface (eg. netif_ed) netproto_ network protocol (eg. netproto_arp) netdomain_ network domain (eg. netdomain_ip) vfs_VFS layer (eg. vfs_nfs) kern_ kernel infrastructure (eg. kern_vfs) syscall_loadable system calls (eg. syscall_sendfile) I like this. It's the best alternative to an arbitrarily deep (and much disputed) directory structure I've seen so far. - Jordan To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: KLD naming
On Tue, 19 Jan 1999, Jeroen C. van Gelderen wrote: Hi, Might it be a good idea to choose a consistent naming scheme for the modules? I'd think so because it would help blind loading at the boot prompt. If you choose names it the following format: type_name saver_warp saver_daemon the modules of one type will sort together in a directory listing. This is a change that will make FreeBSD more user friendly I think. When I first started writing KLD, I had a vague notion that there would be a simple directory structure under /modules, e.g.: /modules pci/ ncr.ko ... isa/ if_ed.ko ... ... Including the type in the filename instead might be a better idea though. -- Doug Rabson Mail: d...@nlsystems.com Nonlinear Systems Ltd. Phone: +44 181 442 9037 To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: KLD naming
Doug Rabson writes: Might it be a good idea to choose a consistent naming scheme for the modules? I'd think so because it would help blind loading at the boot prompt. If you choose names it the following format: type_name saver_warp saver_daemon the modules of one type will sort together in a directory listing. This is a change that will make FreeBSD more user friendly I think. When I first started writing KLD, I had a vague notion that there would be a simple directory structure under /modules, e.g.: /modules pci/ ncr.ko ... isa/ if_ed.ko ... ... I like this idea (subdirectories) better.. it will last longer :-) Witness the explosion of the ports tree. You should then be able to load a module isa/if_ed.ko etc and have it work (no leading slash). In fact, we can implement this (maybe it already works) before coming to a final decision on what the actual layout should be. -Archie ___ Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
