Source-Changes-D archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: CVS commit: src/sys/net
> 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
> dyoung%ojctech.com@localhost Urbana, IL * (217) 278-3933
Home |
Main Index |
Thread Index |
Old Index