> 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. \\ [email protected]
\\ The race is long, and in the \\ [email protected]
\\ end it's only with yourself. \\ [email protected]
To Unsubscribe: send mail to [email protected]
with "unsubscribe freebsd-current" in the body of the message
