netdev - Re: [RFC net-next 0/3] devconf: New infrastructure for setting pre-load parameters for a module

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <loom.20150112T214442-809@post.gmane.org>
Date:	Mon, 12 Jan 2015 21:02:20 +0000 (UTC)
From:	Rob Herring <robh@...nel.org>
To:	netdev@...r.kernel.org
Subject: Re: [RFC net-next 0/3] devconf: New infrastructure for setting pre-load parameters for a module

Amir Vadai <amirv <at> mellanox.com> writes:
> On Thu, Jan 8, 2015 at 9:25 PM, Greg KH <gregkh <at> linuxfoundation.org> 
wrote:
> > On Thu, Jan 08, 2015 at 09:14:32PM +0200, Amir Vadai wrote:
> >> On Thu, Jan 8, 2015 at 7:47 PM, Greg KH <gregkh <at> 
linuxfoundation.org> wrote:
> >> > On Thu, Jan 08, 2015 at 07:11:04PM +0200, Amir Vadai wrote:
> >> >> On 1/8/2015 6:46 PM, Greg KH wrote:
> >> >> > On Thu, Jan 08, 2015 at 05:16:57PM +0200, Hadar Hen Zion wrote:
> >> >> >> Hi,
> >> >> >>
> >> >> >> When configuring a device at an early boot stage, most kernel 
drivers
> >> >> >> use module parameters (the parameters' settings can be determined 
in
> >> >> >> modprobe.d config files).
> >> >> >
> >> >> > Which is a bad idea, as you have learned :)
> 
> [...]
> 
> >
> > But you are talking about loading config info before the driver is
> > loaded, which goes backwards for how we automatically load modules when
> > the hardware is found.
> 
> I guess you're a busy man and getting tired of my nudges. And it is ok
> with us to make it a non-generic solution - so I won't bother you much
> more...
> I would like to understand the arguments here: Maybe there is a
> history that I missed - What are the arguments against having a config
> info before the driver is loaded? Assuming, that it will make the
> driver loading process simpler and faster.

DeviceTree does exactly this. Even discoverable buses sometimes need 
additional information. DT can be used to add additional properties to PCI 
devices for example. I'm not sure DT is a fit here. As a matter of policy to 
be OS independent, the configuration data should be tied to the hardware and 
not purely software configuration. The example of netdev vs. infiniband would 
fit, but I don't know about other cases. Traditionally, DT would be part of 
the firmware/bootloader rather than coupled to the kernel or distro. It is 
not clear to me in your case who does the configuration and when does it 
change. There is new support making its way into the kernel called DT 
overlays which allows loading additional DT data after or during boot. That 
may be a good fit for your use case.

Rob

--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html