On Tue, Nov 4, 2014 at 1:34 AM, Quentin Garnier <c...@cubidou.net> 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 <c...@cubidou.net> 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.