Re: CVS commit: src/sys/dev

[Masao Uebayashi <uebayasi%gmail.com@localhost>]

On Tue, Nov 4, 2014 at 1:34 AM, Quentin Garnier <cube%cubidou.net@localhost> wrote:
> On Tue, Nov 04, 2014 at 01:16:40AM +0900, Masao Uebayashi wrote:
>> On Mon, Nov 3, 2014 at 9:49 PM, Quentin Garnier <cube%cubidou.net@localhost> wrote:
>> > On Sat, Nov 01, 2014 at 07:54:18AM +0000, Masao Uebayashi wrote:
>> >> Module Name:  src
>> >> Committed By: uebayasi
>> >> Date:         Sat Nov  1 07:54:18 UTC 2014
>> >>
>> >> Modified Files:
>> >>       src/sys/dev: audio.c audio_if.h
>> >>
>> >> Log Message:
>> >> Revert previous.
>> >>
>> >> Not only audio_attach_mi() but also audioprint() have to be separated.
>> >> midi.c has the same problem, and a little more complicated.  These will be
>> >> revisited later.
>> >
>> > It's because they are functions for "audiobus" (where audio(4) attaches)
>> > rather than for "audio".  So you can split them into a file that depends
>> > on audiobus.
>>
>> Understood.
>>
>> Let me reprase: "audiobus" is already an interface attribute.  Those
>> functions (audio_attach_mi(), audioprint(), ...) will belong to
>> audiobus.c (or .o, or .ko).  Those drivers providing the "audiobus"
>> interface (e.g. auich(4)) will depend on audiobus module.  So:
>>
>>         device auich: audiobus, ...
>>
>> The funny thing here is, the line has two meaning: a) providing
>> "audiobus" interface, b) depending on "audiobus" module.  Due to the
>> limitation of the config(5) syntax!
>
> I don't see how this particular case is a problem.  Why exposing an
> audiobus interface wouldn't imply depending on the audiobus-specific
> functions?

Well, very probably no problem.  It's only that I was not 100% sure.

>> One question is, when to unload audiobus-as-a-module.  It is depended
>> on by audio if drivers, but it does not depend on anything.  When all
>> audio if drivers are unloaded, there is not reason to keep it in
>> kernel.  Maybe some (smart) ref-counting is needed.
>
> So you moved on to loadable modules now?  I thought your intent was
> .text massaging.

Just thinking and making sure that I'm not going to break it by design.

>> > Most pseudo-buses have that issue I think.  Probably some actual buses
>> > too.  I'd not really expect a kernel that has pchb but not pci selected
>> > to compile.
>>
>> I've not really looked into pseudos yet...
>
> I meant audiobus.  There are a lot of such buses that are not really
> anything but a way to attach a generic device.

Sure.  If I find something odd I'll bring up it somewhere.