Date: Sat, 05 Dec 1998 23:41:11 -0800 From: Mike Smith <mike@smith.net.au> To: Terry Lambert <tlambert@primenet.com> Cc: wpaul@skynet.ctr.columbia.edu (Bill Paul), current@FreeBSD.ORG Subject: Re: New drivers and install floppy space Message-ID: <199812060741.XAA03107@dingo.cdrom.com> In-Reply-To: Your message of "Sat, 05 Dec 1998 22:16:44 GMT." <199812052216.PAA28951@usr05.primenet.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> This is the partial culmination of the benefits of a modular kernel. > > I would suggest that architectural care be given to allowing: Thanks for enumerating the entire list here; I'll just summarise the state of our compliance so far - most of these have already been thought of. > o use of DOS format floppies to conatin the driver Done. We support DOS and UFS floppies, as well as NFS, TFTP and iso9660 filesystems. > o specification of the FS path to the driver directory Root path to information file - I think we should be able to do this, although my preference would actually be to require a 'bsdinfo' file at the top level to make this as automated as possible. > o selection of a default "/freebsd/" directory ... but I like this better. > o a naming format that can return all drivers, but > avoid other (informational, etc.) files, such as > loading everything matching "*.[0-9][0-9][0-9]" in > the driver directory *.ko should do it, although the information that identifies a file as a driver object should be in the metaconfig file. > o support for using drivers from multiple floppies, > one per device Arbitrary number of drivers on an arbitrary number of media. I'm open to suggestions that would allow aggregation without editing a single file. One that occurs is to use the approach that the Lan Manager folks did and say that *.BSD at the top level of the media are directories containing FreeBSD drivers, one per directory. > o a mechanism for dumping drivers from the kernel after > installation so that they need not be installed twice: > once to boot, once to install; this probably implies > driver data areas be mapped copy-on-write to maintain > the data image integrity to allow it to be written > back out This is actually fairly tough, as the entire ELF object is not loaded in the first place. My preference is simply to track the driver(s) that are loaded, and request the use re-provide the media from which the driver was read when it comes time to copy it. > This would allow the FreeBSD project to provide binary drivers > back to vendors for inclusion on their distribution media, and > in general, help raise FreeBSD visibility considerably. Sounds close to our goalset. Feel like writing any of this code, or is that outside your domain of interest? -- \\ Sometimes you're ahead, \\ Mike Smith \\ sometimes you're behind. \\ mike@smith.net.au \\ The race is long, and in the \\ msmith@freebsd.org \\ end it's only with yourself. \\ msmith@cdrom.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199812060741.XAA03107>