Date: Tue, 28 Jan 1997 15:06:47 -0700 (MST) From: Nate Williams <nate@mt.sri.com> To: hosokawa@mt.cs.keio.ac.jp (HOSOKAWA Tatsumi) Cc: mobile@freebsd.org Subject: Re: I want to restructure pccardd.... Message-ID: <199701282206.PAA24236@rocky.mt.sri.com> In-Reply-To: <199701282020.FAA03167@lenlen.mt.cs.keio.ac.jp> References: <199701282020.FAA03167@lenlen.mt.cs.keio.ac.jp>
next in thread | previous in thread | raw e-mail | index | archive | help
> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199701282206.PAA24236>