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] [thread-next>] [day] [month] [year] [list]

Message-ID: <f17812d70808220232o7976680fkbb34528c4b7b000f@mail.gmail.com>
Date:	Fri, 22 Aug 2008 17:32:24 +0800
From:	"Eric Miao" <eric.y.miao@...il.com>
To:	"Pavel Machek" <pavel@...e.cz>
Cc:	LKML <linux-kernel@...r.kernel.org>
Subject: Re: Fundamental Design Flaw of the Device Driver Model?

On Fri, Aug 22, 2008 at 5:03 PM, Pavel Machek <pavel@...e.cz> wrote:
>> Fundamental Design Flaw of the Device Driver Model?
>> ===================================================
>>
>> Sorry for the misleading subject, its purpose is to draw your attention :-)
>> The ideas below are preliminary and I hope I'm not making serious mistakes
>> here.
>>
>> This question has actually been around in my mind for several months, when
>> I started to work on some devices with multiple functions. Specifically, a
>> Power Management IC (PMIC in short in the following text) usually includes
>> LEDs support (charging, indication...) audio, touch screen, power monitoring,
>> LDOs, DC-DC bucks, and possibly some others.
>>
>> The initial two ideas came into my mind were:
>>
>>    1. separate the functions into multiple devices, write a driver for each
>>       of these devices
>
> Go for 1.
>
>>    4. An intermediate device with no bus, no driver, no many other things
>>       is really not something deserving a "struct device", that's a waste
>>       of memory.
>
> Memory is not _that_ expensive, and struct device is not that
> big. Adding infrastructure to driver model for supporting this would
> also cost you memory, this time in .text segment.
>

Actually I don't mind wasting additional memory for a better structure,
but option (1) isn't. And I just assume you have read to the end of thi
 mail, then you will see it's more like a concept change,no fundamental
change to the code itself.

Actually the reason to have two different kind of devices are obvious:

1. physical device - handles the bus related operations (read, write,
locking, I/O)
2. virtual device - handles the functionality (interface with the
upper framework)

With this separation, the same IP on different semiconductor can be
shared naturally. There are lot of such products esp in embedded market,
with multiple shared IPs within a single die.

Attached is a patch series to get you guys a feeling how the option
(1) will look like, and think again about the device-driver relationship,
the correctness of introducing an intermediate platform_device.

View attachment "0001-i2c-add-base-support-for-DA9030-DA9034.patch" of type "text/x-diff" (21590 bytes)

View attachment "0002-leds-add-support-of-on-chip-LED-drivers-for-DA9030.patch" of type "text/x-diff" (6415 bytes)

View attachment "0003-backlight-add-DA9030-DA9034-WLED-based-backlight-su.patch" of type "text/x-diff" (7183 bytes)

View attachment "0004-input-add-touchscreen-interface-found-on-DA9034-PMI.patch" of type "text/x-diff" (11166 bytes)