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] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAP-MU4MzG_P9fz3_eix=zgzyjijZ5qo1mpKE=r_K7y3xcJqc5Q@mail.gmail.com>
Date:	Fri, 11 Jan 2013 11:30:54 -0800
From:	Shannon Nelson <shannon.nelson@...el.com>
To:	Greg KH <gregkh@...uxfoundation.org>
Cc:	netdev@...r.kernel.org, davem@...emloft.net, dwmw2@...radead.org,
	jeffrey.t.kirsher@...el.com, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 0/3] ixgbe: request_firmware for configuration parameters

On Fri, Jan 11, 2013 at 10:25 AM, Greg KH <gregkh@...uxfoundation.org> wrote:
> On Thu, Jan 10, 2013 at 06:02:20PM -0800, Shannon Nelson wrote:
>> Most networking dials and knobs can be set using ethtool, ifconfig, ip link
>> commands, or sysfs entries, all of which can be driven by startup scripts
>> and other configuration tools.  However, they all depend on having a netdev
>> already set up, and we have some low-level device functionality that needs
>> to be sorted out before we start setting up MSI-x and memory allocations.

> Ick, please don't abuse request_firmware() for this type of thing.

Yeah, it seemed ugly to me at first as well, but it grew on me as I
realized that it does solve a problem in a rather elegant way.  While
working this up I discussed this with Mr. Woodhouse thinking that as a
firmware tree maintainer he'd have a similar reaction, but he actually
wasn't opposed to it (David, please speak up if I'm misrepresenting
your comments).

> What's wrong with configfs?  It sounds like it will fit your need, and
> that is what is created for.

configfs has similar problems as sysfs - the driver needs to create
the hooks before it has all the info it might need for some hooks,
there is no persistence across reboots, and I don't think it will help
for initrd images.  Additionally, there would need to be some userland
mechanism to notice that the hooks were there and to feed it the
startup info.  Using a file in the firmware path gives us persistence
and a way for the driver to get info before having to set up
filesystem hooks.  It also gives us a way to get special config info
into the boot image.  And the whole mechanism already exists,
including UDEV hooks that can do more fancy stuff if needed.

sln

-- 
==============================================
Mr. Shannon Nelson         Parents can't afford to be squeamish.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ