linux-kernel - Re: Fundamental Design Flaw of the Device Driver Model?

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: <9e4733910808222054i56d9d481v97df477617445ab8@mail.gmail.com>
Date:	Fri, 22 Aug 2008 23:54:51 -0400
From:	"Jon Smirl" <jonsmirl@...il.com>
To:	"Eric Miao" <eric.y.miao@...il.com>
Cc:	LKML <linux-kernel@...r.kernel.org>
Subject: Re: Fundamental Design Flaw of the Device Driver Model?

On 8/22/08, Eric Miao <eric.y.miao@...il.com> wrote:
> On Fri, Aug 22, 2008 at 10:33 AM, Jon Smirl <jonsmirl@...il.com> wrote:
>  > On 8/22/08, Eric Miao <eric.y.miao@...il.com> wrote:
>  > ======================================================
>  >>    This, however, creates many questions you have to face with:
>  >>
>  >>    1. on what bus shall these sub-devices be?
>  >>       ** this is the reason I choose to use "platform_device", at least they
>  >>       can reside on the platform_bus_type, thus platform_driver can be used
>  >>       for this sub-device
>  >
>  > Another option is making your own bus. If I understand your hardware
>  > it effectively has an internal bus.
>  >
>
>
> That's another option around, but it didn't solve my fundamental question
>  of, (e.g. an PCI card with multiple network interfaces and other functionality):
>
>  Why should I have to create an intermediate device provided that a
>  "struct net_device" already contains a "struct device"? And that
>  device-driver binding, parameter passing (platform_data), bus and
>  other functionalities of this "struct net_device" is not used while
>  that's used solely by that intermediate device (platform_device maybe)?
>
>  They should have perfectly been combined into a single virtual device.
>

First device represent the hardware with the PCI interface for the
card. Instantiating it creates a bus for the card. You then auto add
devices to this bus for each of the sub-devices on the card.  Auto add
is fine in this case since the sub-devices aren't optional.
A multifunction card really is a local private bus with multiple
devices on it. First device is a real device - it's the bus controller
for the multifunction card.

A stranger problem is encountered with audio hardware. The SOC CPU
code loads an i2s/ac97 driver. A generic driver for the audio codec is
also loaded. Now you have to create a strange "fabric" device which
represent the specific PCB the generic codec and SOC have been
soldered into. The fabric driver describes how the codec and CPU are
wired together and if all of the codec functions are brought out to
jacks. For example, you don't want to display an ALSA capture device
if the codec supports it but no mic-in jack has been soldered to the
PCB. Is the fabric device a real device? You can't program it but you
can't get rid of it either.

-- 
Jon Smirl
jonsmirl@...il.com
--
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/