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

Reply via email to