Date: Fri, 09 Jan 2004 00:48:55 -0700 From: Scott Long <scottl@freebsd.org> To: Daniel O'Connor <doconnor@gsoft.com.au> Cc: hackers@freebsd.org Subject: Re: Discussion on the future of floppies in 5.x and 6.x Message-ID: <3FFE5CE7.6010708@freebsd.org> In-Reply-To: <200401091750.59133.doconnor@gsoft.com.au> References: <20040107235737.I32227@pooker.samsco.home> <200401091400.40550.doconnor@gsoft.com.au> <3FFE5211.5040606@freebsd.org> <200401091750.59133.doconnor@gsoft.com.au>
next in thread | previous in thread | raw e-mail | index | archive | help
Daniel O'Connor wrote: > 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. > One thing that FreeBSD _sorely_ lacks is the ability to easily use vendor-supplied driver disks. It is not unusual for a vendor to want to replace a buggy/incomplete driver that is in the base system with one that is better. This is incredibly difficult to do in FreeBSD; some drivers cannot be unloaded after being loaded, some drivers are compiled into the kernel for space considerations. If we design a mice interface for handling module loading/unload, multiple floppies, etc, in the boot-loader, then we solve this problem. Btw, I speak of this first-hand; not having a vendor-friendly method for updating drivers makes FreeBSD very, very hard to support, which means that FreeBSD is less likely to receive support. > 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. > See my comment about blowing out the mfsroot.gz file. If you're not careful with this one then you'll wind up pulling in libcam, which will certainly create a size problem. Don't forget that some driver modules live on the same floppy as mfsroot.gz. Any increase in here means that another driver doesn't fit there and has to go somewhere else. > >>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. Sysinstall is based on the concept that the root filesystem is populated with all of the tools that it needs. It has no concept of looking at other media/filesystems for tools. So, who is going to teach it how to do this? I personally think that this would be a hack anyways. If we need to support an mfsroot.gz that is too big for a single floppy, then we need to invent a way to span it across multiple floppies, not randomly put the tools individually onto whatever floppy isn't full this week. If we are going to do the work to keep floppies, then we need to put in a little effort to do it right and not turn it into a collection of miserable hacks (not more than it already is). Anyways, I've debated this as much as I can. I'm looking forward to someone stepping forward that can demonstrate their commitment and desire to taking care of the release floppies. Scott
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3FFE5CE7.6010708>