> On Sun, Aug 16, 2009 at 05:01:12AM +0000, YAMAMOTO Takashi wrote: >> hi, >> >> > On Fri, Aug 14, 2009 at 06:48:10AM +0000, YAMAMOTO Takashi wrote: >> >> hi, >> >> >> >> > Module Name: src >> >> > Committed By: dyoung >> >> > Date: Thu Aug 13 00:23:32 UTC 2009 >> >> > >> >> > Modified Files: >> >> > src/sys/net: if.c if.h >> >> > >> >> > Log Message: >> >> > Use sysctl(9) to expose to userland each interface transmission >> >> > queue's maximum length, current length, and number of drops. E.g., >> >> > >> >> > % sysctl net.interfaces.bnx0 >> >> > net.interfaces.bnx0.sndq.len = 0 >> >> > net.interfaces.bnx0.sndq.maxlen = 509 >> >> > net.interfaces.bnx0.sndq.drops = 0 >> >> >> >> does it work for xvif interfaces? cf. PR/35074 >> > >> > Probably not. Thanks for bringing this case to my attention. >> > >> > I could change illegal characters in if_xname to dashes or to >> > underscores in the sysctl node name. Or I could name the node after the >> > if_index instead of after the if_xname, if the if_xname contains illegal >> > characters. I guess that I like the latter idea better. What do you >> > think? >> >> why do you want to use sysctl rather than eg. ioctl? > > I like sysctl interfaces because they are self-describing, granular, > hierarchical, and direct.
sorry, honestly speaking, none of them sounds like a good excuse to start using sysctl for purposes which already have an existing api. i guess that it's too late to throw ioctl away. > It is easy for userland to name sysctl > interfaces to permit/restrict their visibility and use by a user or a > process, and that is something I want to do in the future. in that case, what to do for existing ioctl-based operations? YAMAMOTO Takashi > > Dave > > -- > David Young OJC Technologies > dyo...@ojctech.com Urbana, IL * (217) 278-3933
