Date: Tue, 13 Apr 1999 05:19:41 +0800 From: Peter Wemm <peter@netplex.com.au> To: NAKAGAWA Yoshihisa <y-nakaga@nwsl.mesh.ad.jp> Cc: Mike Smith <mike@smith.net.au>, "Daniel C. Sobral" <dcs@newsguy.com>, Nate Williams <nate@mt.sri.com>, Ted Faber <faber@ISI.EDU>, Nick Sayer <nsayer@quack.kfu.com>, freebsd-mobile@FreeBSD.ORG Subject: Re: Any success with CirrusLogic 6729/6730??? Message-ID: <19990412211943.D73151F4F@spinner.netplex.com.au> In-Reply-To: Your message of "Mon, 12 Apr 1999 16:54:25 %2B0900." <199904120754.QAA09135@chandra.eatell.msr.prug.or.jp>
next in thread | previous in thread | raw e-mail | index | archive | help
NAKAGAWA Yoshihisa wrote: > > This is specifically why we still use hint information from the > > configuration file. The goal, however, is to get away from compiling > > that hint information into the kernel. > > # newconfig members' (me too) opinion below: > > Our newconfig is better than yours new-bus in this point. > Newconfig supports both dynamic configration and static configuration, > so newconfig can do what new-bus can do, and also newconfig can > support particular configurations which new-bus can't. > (e.g. specially tuned kernel for particular purpose.) This is not correct. Perhaps you are misunderstanding what we're trying to do. Under newconfig, the static (or fixed) configuration is compiled into the binaries. What we're trying to do is get that out of the binaries and get the information from elsewhere. Part of that can come from probing, part comes from the drivers themselves (they know what they can attach to), and part comes from the fixed configuration fetched from somewhere else. In our case, this would probably come from the loader(8) as a plain text file in /boot. In other words, we would not be loosing any ability to specify particular configurations or to lock down unit numbers etc, but with new-bus you would not have to recompile the kernel to change an IRQ for an ISA card, you would just edit /boot/isa.conf or something like that. In fact, we can probably change the configuration at runtime for things like isa cards. Imagine a generic NE2000 card without PnP that you are not sure of the settings. Suppose you take a guess and when the system boots, it doesn't find it because you guessed the wrong IO port. Since the static/ fixed/whatever ISA config would have been loaded and would be changeable at runtime, it would be possible to change the base port and force a reprobe with the new settings. You could try several times before guessing right, without any kernel recompiles or reboots. You could then update the static/fixed config in /boot/isa.conf for the next time. > Also, in newconfig case, we don't have to load the code which support > an ISA PCIC, if only an PCI PCIC code is needed, because we split an > PCIC driver to three part, an ISA attachment, an PCI attachment, and > bus independent shared part. In new-bus case, we suppose that you > have to load both the code which supports an PCI PCIC and the code > which supports an ISA PCIC. So, newconfig kernel is smaller and > faster to boot and more dynamic than new-bus. It's the same as new-bus, there is no difference at all. You can have the bus-specific parts in seperate modules and use the dependencies to load it with a single command. Or, if you want to keep the number of modules minimized, you can put them all in the same module. You have the choice. For a single kernel image, the present config(8) skeleton doesn't know about 'and' clauses, but this would be fixed at some point. (ie: if the buslogic driver is split into bt.c, bt_isa.c bt_pci.c bt_eisa.c, config isn't smart enough to know that 'controller bt0' when you don't have an eisa bus then you can leave out the bt_eisa.c component. The present hack is to use an #ifdef, but that isn't very good. This will get revisited. This is a weakness in the config(8) hack, not a weakness in new-bus.) > Especially because new-bus doesn't have the feature to treat the > shared part of the device driver like this. Yes it does.. The kld loader was originally written with dependency support with things like this in mind. Cheers, -Peter To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-mobile" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19990412211943.D73151F4F>