svn commit: r275136 - in head/sys: dev/e1000 dev/ixgbe kern sys

[Alfred Perlstein]

> On Dec 1, 2014, at 7:49 AM, John Baldwin <jhb at freebsd.org> wrote:
> 
>> On Monday, December 01, 2014 07:19:13 AM Alfred Perlstein wrote:
>> John,
>> 
>> Will work on a new revision based on feedback.
>> 
>> Two things to note however:
>> 
>> Already explored the idea of using kernel_sysctlbyname but rejected due to
>> following:
>> 
>> It makes little sense to have a rw sysctl that only takes effect "some
>> times". This violates POLA at the expense of making code appear cleaner.
>> Expectation is that writable sysctls take effect or are read only. They are
>> not to be "write sometimes" unless we are to introduce a new flag. Instead
>> of going to a confusing model we consider some form of rw sysctl that can
>> set itself ro somehow. Otherwise people will be confused as to why nic
>> queues says N while actually M.  What the rw->ro api would look like I have
>> no idea. Suggestions?
> 
> This is only somewhat true.  In the near distant future we will have a devctl 
> tool which would let you do 'devctl detach igb0 && devctl attach igb0' which 
> would honor your post-boot setting of hw.igb.num_queues.  Instead what is 
> important to understand about this particular sysctl node is that it only 
> takes affect when a device is attached.  However, there are other control 
> knobs that also only affect future operations and not existing instances of 
> objects, so I don't think this is that big of a leap.
> 

Strongly disagree here.  If I were not able to grok the c code I would be very confused by such a thing. In fact even with the fact that I do grok c code I would be very discouraged to find such behavior and strongly object to writable sysctls that do nothing. 

The ux is that the user has a bunch of dials on their dashboard that function as a busybox as opposed to doing what they are advertised to do. Sort of like those crossing light buttons in New York City that aren't actually hooked to anything. 

So: No. Frankly would rather back out the change entirely and keep this change local to us than expose users to such a UX. 

I will however like to discuss the possibility of a tunable/sysctl system that makes sense. 

-Alfred. 



> -- 
> John Baldwin
>