Re: Patch to support drivers compiled into the kernel

[Kay Sievers <kay sievers vrfy org>]

On Tue, Mar 3, 2009 at 18:48, Dan Williams <dcbw redhat com> wrote:
> On Tue, 2009-03-03 at 18:38 +0100, Kay Sievers wrote:
>> On Tue, Mar 3, 2009 at 16:21, Dan Williams <dcbw redhat com> wrote:
>> > On Tue, 2009-03-03 at 09:54 -0500, Bill C Riemers wrote:
>> >> Currently, NetworkManager ignores any network driver that does not have
>> >> a loadable module associated with it.   This is a problem, when the
>> >> network driver has been compiled directly into the kernel.  This is
>> >> typically done for coLinux, and other environments where a loadable
>> >> module network driver is not supported.
>> >>
>> >> The following patch marks the driver for such devices as "<kernel>", so
>> >> that NetworkManager will not ignore them.   However, NetworkManager will
>> >> still ignore network devices which do not have a driver associated with
>> >> them and is not built-in as part of the kernel.
>> >>
>> >> Note: I created this patch on Fedora 10, against the 0.7.0-1 version.
>> >> Please let me know if I need to do a git checkout and rebuild this patch
>> >> against the current code base.
>> >
>> > Hmm, I'd like to see what sysfs looks like for these devices; do you
>> > have a /sys/class/net/ethX/device directory for that device, and if so,
>> > what's in it?
>>
>> There should be no difference, maybe some "module" link does not exist
>> if it's built-in, but usually even they are created.
>>
>> These days, even /sys/module/ should be identical for modules and
>> built-in code, besides the "refcount" and the sections "attributes"
>> which only exist for loadable modules.
>
> Yeah; it used to be the case that drivers wouldn't call the right bits
> to get the device link which would then provide the driver.

Right, the driver should be determined by finding the first parent
device which has a "driver" link. The "device" link should not be used
for anything else than finding the parent device in ancient kernels.
In modern kernels, all parent devices are part of the devpath of the
device itself. The position of the device link might change with valid
kernel changes, when devices need to be inserted into the chain of
devices.

> I'm not
> convinced the patch is the right way to go until we figure out if the
> driver is the culprit.

Yeah, the patch does not look right. I would expect the driver does
not set the right parent device at all.

Kay