Date: Fri, 9 Jan 2004 17:50:59 +1030 From: "Daniel O'Connor" <doconnor@gsoft.com.au> To: Scott Long <scottl@freebsd.org> Cc: hackers@freebsd.org Subject: Re: Discussion on the future of floppies in 5.x and 6.x Message-ID: <200401091750.59133.doconnor@gsoft.com.au> In-Reply-To: <3FFE5211.5040606@freebsd.org> References: <20040107235737.I32227@pooker.samsco.home> <200401091400.40550.doconnor@gsoft.com.au> <3FFE5211.5040606@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Friday 09 January 2004 17:32, Scott Long wrote: > > Scott also said stuff like SCSI cards won't get probed if a module is > > loaded but I can't see why that is true.. The module will load, the > > device get detected, and then sysinstall is told to reprobe the hardware, > > so it should pick it up. > > Incorrect. Scanning SCSI buses is something that does not happen > automatically. There is magic in the boot process that makes it happen > near the end, right before the kernel looks for the root device. > However, that is the exception to the rule. If you load a SCSI driver > after the kernel has booted, the SCSI channel behind it will _not_ be > probed automatically. Trust me on this one. Fixing this particular > problem is well beyond the scope of fixing floppies in general. Until > it gets fixed, floppies will just have to deal with it. Yech sucky :( > > I see the 'which kld goes with what device' problem as separate to this > > issue. The KLD load stuff DOES show a small description for each KLD so > > it isn't a total black box, and heck, you can just pick everything and > > cross your fingers :) > > Take something like the if_dc(4) driver. It covers literally _dozens_ > of cards and chips, all under different brands and manufacturers. There > is no way that a single line description file will tell you if your > hardware is supported by the if_dc driver. But this is a minor nit. Yes.. > As I've stated before, loading kernel modules after the kernel has > booted is the wrong time to do it. The loader needs to be enhanced to > be able to take care of this. Once that happens, we can trivially > modify the release scripts to allow an arbitrary number of driver > floppies to be created, and the maintenance nightmare goes away for > the most part. I don't necessarily agree here - I think sysinstall is a better place because it's much much easier to write stuff for it than the loader. In the example you mention the only reason to use the loader is because the SCSI subsystem won't reprobe when a new SCSI bus comes online which sounds like a bug. BTW Does camcontrol rescan cause the devices to be detected? Perhaps sysinstall could be "enhanced" to perform this duty as part of it's reprobe machinations. > Well, except when mfsroot.gz becomes too large to fit on a single > floppy. Right now it is about 90k away from that. What happens when > mount_nfsv4 gets put on there? John Baldwin and I already spat ent a > day over the holiday break making the mfsroot.gz image fit given the > new requirements created by having a dynamic root. What happens the > next time that it overflows? It's not like the driver floppies where > you can dike more stuff to another disk; this is a single image. Do > we come up with a method for having multiple, segmented images? Who > writes the code to do that? > > If we are going to keep floppies, then we need people who are willing to > tackle these issues and keep them under control. I agree with that! :) However, given your example above, I would just put mount_nfsv4 on another floppy, although if sysinstall (or it's replacement) is too large, there will need to be the ability to load N floppy images into memory. However they're issues for floppy users ;) -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 9A8C 569F 685A D928 5140 AE4B 319B 41F4 5D17 FDD5
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200401091750.59133.doconnor>