From owner-freebsd-mobile Tue Jan 28 14:07:35 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id OAA14028 for mobile-outgoing; Tue, 28 Jan 1997 14:07:35 -0800 (PST) Received: from rocky.mt.sri.com (rocky.mt.sri.com [206.127.76.100]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id OAA14022 for ; Tue, 28 Jan 1997 14:07:25 -0800 (PST) Received: (from nate@localhost) by rocky.mt.sri.com (8.7.5/8.7.3) id PAA24236; Tue, 28 Jan 1997 15:06:47 -0700 (MST) Date: Tue, 28 Jan 1997 15:06:47 -0700 (MST) Message-Id: <199701282206.PAA24236@rocky.mt.sri.com> From: Nate Williams To: hosokawa@mt.cs.keio.ac.jp (HOSOKAWA Tatsumi) Cc: mobile@freebsd.org Subject: Re: I want to restructure pccardd.... In-Reply-To: <199701282020.FAA03167@lenlen.mt.cs.keio.ac.jp> References: <199701282020.FAA03167@lenlen.mt.cs.keio.ac.jp> Sender: owner-mobile@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > I'm planning to rewrite pccardd (and related interface of sys/pccard) > from scratch because, > > 1. To extend the syntax of pccard.conf is very difficult because it > uses a parser written in plain C. True, but see below. > 2. Very early version of pccardd only supports one I/O window and > fixed parameters, etc. I added many hack to overcome these limits. > But now, I want to support complete PnP resource configuration of > PC-cards and I want to add multifunction card support. I tried to > add these features as hack for pccardd, but it's too difficult. I > abandoned this project. 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.) > 3. The current design of 'ether' subcommand in pccard.conf is not good > because it mainly focuses upon support for NE2000 compatible cards > (I'm talking about how pccardd uses 'misc' member of slot > structure, not about the syntax of pccard.conf). Agreed. That's why it's not in -current. :) :) > I want to implement new pccardd in C and lex/yacc. I'm nurvous about > programming language because I was involved in a flame war in another > mailing list about the programming language of metaconfiguration > system of kernel structure :-), but I think C is the best language for > this purpose. I think Perl (and Tcl) can be alternative, but using a > fat interpreter is bad idea for daemons, and utilities incorporated > into boot.flp. > > Any comments? 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. Currently, it does lots of selecting of resources, and I believe this is a bad thing for a couple of reasons. 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. 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.) 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 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. 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? Nate