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
_______________________________________________ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
