Date: Wed, 29 Jan 1997 08:34:25 -0700 (MST) From: Nate Williams <nate@mt.sri.com> To: hosokawa@mt.cs.keio.ac.jp (HOSOKAWA Tatsumi) Cc: nate@mt.sri.com, mobile@freebsd.org Subject: Re: I want to restructure pccardd.... Message-ID: <199701291534.IAA27310@rocky.mt.sri.com> In-Reply-To: <199701290727.QAA03592@lenlen.mt.cs.keio.ac.jp> References: <199701282206.PAA24236@rocky.mt.sri.com> <199701290727.QAA03592@lenlen.mt.cs.keio.ac.jp>
next in thread | previous in thread | raw e-mail | index | archive | help
> >> Multifunction card support shouldn't be too hard to add, but this also > >> requires some non-significant kernel modifications. (Though they aren't > >> too terribly difficult.) > > Yes. Shared IRQ allocation, etc. It's not terribly difficult, but > it's so difficult that I don't want to go on with current > implementation of pccardd :-). Agreed. The user-land code is a real mess, but IMHO most of it is not due to bad design, but due to lots of 'magic' in the CIS tuple code. > >> 1) It doesn't know what resources are *really* available. The kernel > >> knows (or can be modified) which ports are free, which IRQ's are > >> unused, etc.. The user-land code does not. > > Yes. I'm planning to implement PC-card utility automatically adds new > pccard.conf entries of unknown cards like PC-card manager of Windows > 95 (as an extention of xpccard, or implement new utility). > > For example, if you plug unknown PC-card to the machine, and pccardd > has no definition of corresponding pccard.conf entry in the database, > pccardd notices this event, pccardd passes it to user interface client > or record it as syslog. User interface client prompts user to specify > the corresponding driver from menu system. If users specify > appropriate driver, user interface utility passes it to pccardd, and > pccardd kicks ther kenel to initialize the driver with specified > driver. If it succeeds, it will add to /etc/pccard.conf.local. > > If I add a feature that user interface utility to prompt user to > e-mail me the new pccard.conf entry, it will make us and you happy :-). *grin* This is nice, but it's really not in the scope (yet) of re-writing pccardd. > >> 2) You can't boot from a PCCARD disk/FLASH card simply because you have > >> to be running in multi-user mode before it will be recognized. By > >> moving alot of the resource handling in the kernel it would be easier > >> to have a really simple CIS reader in the kernel for embedded > >> systems. (Easier said than done.) > > Hmm. That's true. I think we also have to add a feature function to > isolate any slot from pccardd's management. True, I hadn't even thought about that. If the kernel is handling things you certainly don't want it changing things out from under the kernel. > >> 3) It requires too much 'card-specific' information to be > >> known/understood by the user. > >> > >> I'd like to see a much simpler syntax, rather than a more complicated > >> syntax used in /etc/pccard.conf. > >> > >> Ie: > >> card "3Com Corporation" "3C589" > >> driver 'ep' > >> insert echo "3Com Etherlink III inserted" > >> insert /etc/pccard_ether ep0 -link0 link1 > >> remove echo "3Com Etherlink III removed" > >> remove /sbin/ifconfig ep0 delete > > Very good. I want to remove index specification and IRQ specification. Me too. > >> And, the card daemon would pass the 'available' parameters it can use > >> to the kernel, instead of picking one. The user-land daemon could build > >> up the list of 'usable' configurations and the kernel could choose the > >> one that matched it's list of available resources. > > Yes, we have to add an interface to get resource map from userland > daemon. Most of this is already there, we just need to extend it. > >> I think this would make things *much* easier to deal with, but would > >> still leave most of the complexity (CIS tuple reading) in user-land. > >> > >> And, if you had a 'known' CIS tuple the kernel could do a simple > >> recognition on it and boot from it. (Again, this would be useful to > >> embedded systems who are less concerned about people throwing in funky > >> new PCCARDs). > >> > >> What do you think? > > Flash ATA and HDD PC-card can be handleed by most BIOSses on laptops, > but booting from SCSI PCMCIA or Ethernet PCMCIA is very challenging > work :-). Very true, but I suspect it can be done. In any case, I'm not sure this needs a 'new lex/C' syntax for /etc/pccard.conf, but feel free to convince me otherwise. It would be *really* nice if we could write the CIS parser in lex though. :) :) Nate
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199701291534.IAA27310>