Date: Tue, 13 Jul 1999 16:01:23 -0700 From: Mike Smith <mike@smith.net.au> To: Warner Losh <imp@village.org> Cc: mobile@freebsd.org Subject: Re: pcic module Message-ID: <199907132301.QAA01742@dingo.cdrom.com> In-Reply-To: Your message of "Tue, 13 Jul 1999 16:47:50 MDT." <199907132247.QAA50546@harmony.village.org>
next in thread | previous in thread | raw e-mail | index | archive | help
> In message <199907132231.PAA01546@dingo.cdrom.com> Mike Smith writes: > : It was a half-complete idea. Ideally it should be a loadable bus type, > : but it's not useful in its current form. > > Right, but in order to be useful, the loadable bus type should also > make it possible to have loadable bus attachments to that bus... Hmm. Ideally, the driver should contain all the bus methods that are supported, and should be loadable even if the bus support isn't present in the kernel. This all harks back to the most-general-module-possible concept. Perhaps a halfway approach would be to aggregate all of the bus interface modules into the same object file as the driver, but only actually connect the modules that are required at load time. > We may also need to convince new-bus driver writers to allow for this > as well (eg for each driver foo, there should be a foo_pccard.c and/or > foo_cardbus.c that can be loaded so that the foo device can be > attached to the newly loaded device). Right now the bus attachment > code tends to be intermingled with the bus independent code... But > this is starting to drift back to the "how to organize the driver > tree" thread, which might be dangerous :-). Not at all. Now is the time to lay this down, and I think you're right on the money. Each bus:driver pair probably needs to be its own module, ie. for the 'ed' driver you have: Module File ------------------------------- if_ed if_ed.c if_ed_isa if_ed_isa.c if_ed_pci if_ed_pci.c if_ed_pccard if_ed_pccard.c ad nauseam. In each case, the bus-specific modules all depend on the if_ed module. > I guess it boils down to > how fine a granularity we want to have in loading/unloading > drivers... How much RAM is wasted by having all possible attachment > drivers present in each driver vs the complexity of just loading the > cardbus attachment code and not the pci attachment code. My guess is > that the complexity would be higher with only a minimal savings in RAM > space. We can reduce the complexity by aggregating them all into one object, which keeps the dependancy stuff out of the way for now (until we fix that), plus it lets people tweak the module size down by leaving parts out if they want to roll their own. > Some mechanism does need to exist to map the pccard card and cardbus > card information to a specific driver in FreeBSD. If we have a > userland daemon, which I'd like to avoid, we can just do a table > lookup in some config file, load the module and then attempt to > probe/attach it. However, if it is all kernel based, I'm not sure how > we can accomplish that since I don't think that the kernel can > initiate a module load.... Yes, it can. > A similar mechanism would be needed if we wanted to > have some way to only load those devices that are detected at boot > time, and unload the rest. pccard and cardbus cards make this problem > potentially harder since they come and go at any time... They're also virtually impossible to detect from the loader, which will ideally be able to deal with auto-preloading drivers for detected hardware. Just as an aside, I suspect this is why NT won't let you hotswap pccards; they do their pccard detection in their loader, but don't have any support for it in the kernel proper. -- \\ The mind's the standard \\ Mike Smith \\ of the man. \\ msmith@freebsd.org \\ -- Joseph Merrick \\ msmith@cdrom.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-mobile" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199907132301.QAA01742>