Date: Mon, 1 Dec 2014 07:55:57 -0800 From: Alfred Perlstein <bright@mu.org> To: John Baldwin <jhb@freebsd.org> Cc: "svn-src-head@freebsd.org" <svn-src-head@freebsd.org>, "svn-src-all@freebsd.org" <svn-src-all@freebsd.org>, Alfred Perlstein <alfred@freebsd.org>, "src-committers@freebsd.org" <src-committers@freebsd.org> Subject: Re: svn commit: r275136 - in head/sys: dev/e1000 dev/ixgbe kern sys Message-ID: <6753416A-D6FD-47F4-A62E-99A6ABB9B4B2@mu.org> In-Reply-To: <1762770.yx1cv63jp7@ralph.baldwin.cx> References: <201411262019.sAQKJaw4043557@svn.freebsd.org> <39377603.10OyiSzjWY@ralph.baldwin.cx> <872C180A-6ADD-469F-A801-3728DF134EEC@mu.org> <1762770.yx1cv63jp7@ralph.baldwin.cx>
next in thread | previous in thread | raw e-mail | index | archive | help
> On Dec 1, 2014, at 7:49 AM, John Baldwin <jhb@freebsd.org> wrote: >=20 >> On Monday, December 01, 2014 07:19:13 AM Alfred Perlstein wrote: >> John, >>=20 >> Will work on a new revision based on feedback. >>=20 >> Two things to note however: >>=20 >> Already explored the idea of using kernel_sysctlbyname but rejected due t= o >> following: >>=20 >> 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 a= re >> not to be "write sometimes" unless we are to introduce a new flag. Instea= d >> 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 ha= ve >> no idea. Suggestions? >=20 > This is only somewhat true. In the near distant future we will have a dev= ctl=20 > tool which would let you do 'devctl detach igb0 && devctl attach igb0' whi= ch=20 > would honor your post-boot setting of hw.igb.num_queues. Instead what is=20= > important to understand about this particular sysctl node is that it only=20= > takes affect when a device is attached. However, there are other control=20= > knobs that also only affect future operations and not existing instances o= f=20 > objects, so I don't think this is that big of a leap. >=20 Strongly disagree here. If I were not able to grok the c code I would be ve= ry confused by such a thing. In fact even with the fact that I do grok c cod= e I would be very discouraged to find such behavior and strongly object to w= ritable sysctls that do nothing.=20 The ux is that the user has a bunch of dials on their dashboard that functio= n as a busybox as opposed to doing what they are advertised to do. Sort of l= ike those crossing light buttons in New York City that aren't actually hooke= d to anything.=20 So: No. Frankly would rather back out the change entirely and keep this chan= ge local to us than expose users to such a UX.=20 I will however like to discuss the possibility of a tunable/sysctl system th= at makes sense.=20 -Alfred.=20 > --=20 > John Baldwin >=20
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?6753416A-D6FD-47F4-A62E-99A6ABB9B4B2>