> 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
