Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 13 Jul 1999 16:47:50 -0600
From:      Warner Losh <imp@village.org>
To:        Mike Smith <mike@smith.net.au>
Cc:        mobile@freebsd.org
Subject:   Re: pcic module 
Message-ID:  <199907132247.QAA50546@harmony.village.org>
In-Reply-To: Your message of "Tue, 13 Jul 1999 15:31:56 PDT." <199907132231.PAA01546@dingo.cdrom.com> 
References:  <199907132231.PAA01546@dingo.cdrom.com>  

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...

I agree that someday this stuff should be loadable, and that it should
be possible to load the pccard/card bus module, any support code for
drivers (eg if_ep) and things should just work.  For the moment,
too many things are desided at compile time to make pcic a viable
module.

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 :-).  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.

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....  Unless there are some plans for doing this
in the future that I've not heard of.  In the discussions so far, I've
always seen some external agent initiate the loading (eg kldload or
the boot loader).  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...

Warner


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?199907132247.QAA50546>