Date: Wed, 29 Jan 1997 16:27:01 +0900 (JST) From: hosokawa@mt.cs.keio.ac.jp (HOSOKAWA Tatsumi) To: nate@mt.sri.com Cc: mobile@freebsd.org, hosokawa@mt.cs.keio.ac.jp Subject: Re: I want to restructure pccardd.... Message-ID: <199701290727.QAA03592@lenlen.mt.cs.keio.ac.jp> In-Reply-To: Your message of Tue, 28 Jan 1997 15:06:47 -0700 (MST). <199701282206.PAA24236@rocky.mt.sri.com>
next in thread | previous in thread | raw e-mail | index | archive | help
In article <199701282206.PAA24236@rocky.mt.sri.com> nate@mt.sri.com writes: >> 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. That's why it's not in -current. :) :) :-). >> I'd like to see pccardd become *much* simpler. Basically, the only >> thing the userland utility should have to do is: >> 1) Figure out the card <-> kernel driver mapping >> 2) Read the CIS structures and pass in all relevant information to >> the kernel. Agree. >> 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 :-). >> 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. >> 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. >> 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. >> 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 :-). -- HOSOKAWA, Tatsumi hosokawa@mt.cs.keio.ac.jp hosokawa@jp.FreeBSD.org
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199701290727.QAA03592>