Re: How to add a new bootdevice to the new boot code ???
It seems Mike Smith wrote: But hey, I don't have the time to work on ATAPI. Soren does, so he gets to call the shots. Right :) ... so we lose. 8( Well, depends on POV I guess... Soren, please take a little time to understand what Justin is talking about. The parts of CAM that are relevant to you are the queueing support, infrastructure, and the separation between the interface controller and the peripheral driver, something that you've indicated to me several times that you simply don't grasp. The main driving force here is that I want as much performance as I can possibly get out of modern ATA/ATAPI hardware, plus have a driver as simple as possible to arrive at that goal. However, all that I've been doing so far is to get the lowlevel code redone so probes are faster etc etc, all the highlevel code is more or less reused old hat things for now. There is nothing that hinders anyone in doing all the (apparently) needed changes to CAM, and have it call what I've (re)done so far. However I dont have any plans for that on my whiteboard *currently*. If consensus can be reached that shows that the project is not interested in it being done this way, please, just tell me and I'll pack up my bits, I can deal with having yet another set of patches locally. Can you grasp that ?? (yes offence taken). Taking advantage of all the code and design that's already been implemented in the CAM framework will make your life easier, not harder. It's not necessary to write a translation layer at all, if such a thing offends your sensibilities. Maybe, later, but I still need to get all the lowlevel stuff into shape, and have it working on you average ATA/ATAPI iron, which is not exactly trivial, I need support for DMA on god knows which different PCI chipsets, I need the lowlevel code to deal with ATA4's braindead way of doing tagged queuing, etc etc etc.. Then when all this is working we can talk about having the top layer(s) redone in the CAM way or what we have at that point in time. OK ?? -Søren To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: How to add a new bootdevice to the new boot code ???
It seems Justin T. Gibbs wrote: My main complaint so far about the new ATAPI stuff is that it duplicates or lacks (assuming it will be implemented) much of what CAM would have given for almost free: - Interrupt driven configuration That there allready, if we mean the same thing here. Right. Its duplicated functionality. Nope, not exactly.. - Peripheral driver to device routing Such as ? Such as the ability to have more than one driver share the same device, command generation counts and priority queuing to allow correct 'replay' of overlapped commands when an error occurs, etc. See: http://www.freebsd.org/~gibbs/cam.html That will probably need changes to work with ATA4's tagged queing at least... - an extensible error recovery framework Well, here is room for improvement, I haven't put any real error checking code in there by now, it will just fail and report that for now. This is alpha level code remember. But how will you deal with errors especially when there are overlapped commands? CAM already deals with this in a very clean way. When an error occurs, the controller driver freezes the queue of commands to the erring device, notifies the peripheral driver of the error, and allows the driver to insert error recovery actions before any other commands are ever released to the device. This even allows you to toss back unexecuted but queued commands at the controller level to be reinserted into the transport layer's command queue to ensure proper ordering. This all plays off of the priority features inherent in how transactions are queued. Command queuing was a major factor in why I wrote the CAM code. Solving these issues is not trivial. Agreed, but have you looked at how ATA4 handles queing ?? - an aplication pass-thru interface Hmm, what for ?? cdrecord, a userland disk format utility, camcontrol functionality, etc. etc. He he, ATAPI dont need cdrecord as all ATAPI burners use the same command set (MMC), where your average SCSI burner has its own propietary command set (well, the ATA/ATAPI guys did get one thing right :) ), There might be an idea for formatting utils for LS120/ZIP drives, ATA harddisks should not be formatted, in fact the ignore the command more or less. OK, I'm done discussing this (se my other mail), I'd rater spend my (very limitted) time productively. -Søren To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: How to add a new bootdevice to the new boot code ???
However Justin's random number comment speaks back to a technique I was working on earlier, where such a number would be secreted in the disklabel of the disk to be booted. This number would have to be generated in a fairly unique fashion (I planned to use the TOD to try to keep it from wrapping), and it'd then be passed in in the environment or as an argument to the kernel. How would that work with netboot or booting from foreign fs, such as FAT? Netbooting is easy, as we can pass an unmabiguous identifier for the remote filesystem to the kernel (the loader and the kernel share the same context on this). Booting from a FAT filesystem isn't a reality until DEVFS arrives, and at that point we have a pile more options available to us again. I wouldn't be too concerned about that just yet. If we restrict ourselves to disklabel-carrying fs, an alternative would be writing the datetime plus a semi-random number (such as time down to ms) on the disklabel of the disk selected, and passing this number to the kernel. [reads what you said again] Unless, of course, that's precisely what you are talking about... Correct. I was looking for a field in the disklabel that I could spam with a suitable number based on the time from the RTC, and I'd then pass that number and the disklabel checksum into the kernel. The only way that this would break would be in the face of tight circumstance and the clock going backwards. However, there's another technique which would work quite well, and one I'm actually moderately enamoured of (modulo it's ability to confuse the heck out of people). Use the last mounted on field to find and mount filesystems. Again, same objections... :-) Same solutions. Plus we'd be likely to place some metadata somewhere on a FAT filesystem, so it'd be trivial to put such a field there. -- \\ Sometimes you're ahead, \\ Mike Smith \\ sometimes you're behind. \\ m...@smith.net.au \\ The race is long, and in the \\ msm...@freebsd.org \\ end it's only with yourself. \\ msm...@cdrom.com To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: How to add a new bootdevice to the new boot code ???
Correct. I was looking for a field in the disklabel that I could spam with a suitable number based on the time from the RTC, and I'd then There isn't one. Especially when there is no disklabel or a read-only disklabel. Again, same objections... :-) Same solutions. Plus we'd be likely to place some metadata somewhere on a FAT filesystem, so it'd be trivial to put such a field there. Similar objections. Disks should be write protected to inhibit spam :-). I pass foo from 1:foo(2s1a)kernel in my version of the old boot blocks. Bruce To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: How to add a new bootdevice to the new boot code ???
- Peripheral driver to device routing Such as ? Such as the ability to have more than one driver share the same device, command generation counts and priority queuing to allow correct 'replay' of overlapped commands when an error occurs, etc. See: http://www.freebsd.org/~gibbs/cam.html That will probably need changes to work with ATA4's tagged queing at least... I just read the ATA5 draft (couldn't find the last ATA4 draft at the wdc website). I don't see any issues here other than the fact that the effect of overlapped commands on data integrity seems to be unspecified. Are they always handled in FIFO order? Can reads be seek optimized? What happens in the case of a queued write after a queued read to the same location? My hope is that, since the spec does not allow you to specify the sorting restrictions on a per request basis as you can in SCSI, FIFO ordering is implied. They even mention that the feature is intended to overlap command processing latency without mentioning the possibility of other optimizations, so perhaps this really is the case. Too bad they didn't just define the two bits necessary (and left as spares in the tag specification register) to allow the same queuing feature set as SCSI. Command queuing was a major factor in why I wrote the CAM code. Solving these issues is not trivial. Agreed, but have you looked at how ATA4 handles queing ?? Yes. - an aplication pass-thru interface Hmm, what for ?? cdrecord, a userland disk format utility, camcontrol functionality, etc. etc. He he, ATAPI dont need cdrecord as all ATAPI burners use the same command set (MMC), where your average SCSI burner has its own propietary command set (well, the ATA/ATAPI guys did get one thing right :) ), Almost all newer SCSI cd burners use MMC now and cdrecord supports MMC devices. Why write another utility if there is already one that speaks the necessary language that our users are familiar with? OK, I'm done discussing this (se my other mail), I'd rater spend my (very limitted) time productively. Fair enough. -- Justin To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: How to add a new bootdevice to the new boot code ???
Correct. I was looking for a field in the disklabel that I could spam with a suitable number based on the time from the RTC, and I'd then There isn't one. Especially when there is no disklabel or a read-only disklabel. Again, same objections... :-) Same solutions. Plus we'd be likely to place some metadata somewhere on a FAT filesystem, so it'd be trivial to put such a field there. Similar objections. Disks should be write protected to inhibit spam :-). I'm happy to entertain any alternate solutions. I pass foo from 1:foo(2s1a)kernel in my version of the old boot blocks. And you determine foo how? -- \\ Sometimes you're ahead, \\ Mike Smith \\ sometimes you're behind. \\ m...@smith.net.au \\ The race is long, and in the \\ msm...@freebsd.org \\ end it's only with yourself. \\ msm...@cdrom.com To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: How to add a new bootdevice to the new boot code ???
I pass foo from 1:foo(2s1a)kernel in my version of the old boot blocks. And you determine foo how? I type it into the config file or the command line. Bruce To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: How to add a new bootdevice to the new boot code ???
I pass foo from 1:foo(2s1a)kernel in my version of the old boot blocks. And you determine foo how? I type it into the config file or the command line. And you submit that this is an acceptable solution? -- \\ Sometimes you're ahead, \\ Mike Smith \\ sometimes you're behind. \\ m...@smith.net.au \\ The race is long, and in the \\ msm...@freebsd.org \\ end it's only with yourself. \\ msm...@cdrom.com To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: How to add a new bootdevice to the new boot code ???
I pass foo from 1:foo(2s1a)kernel in my version of the old boot blocks. And you determine foo how? I type it into the config file or the command line. And you submit that this is an acceptable solution? Of course. The FreeBSD device name won't change (modulo implementation bugs), and even when it does, changing the config file is easier than changing /etc/fstab. Note that there is, or should be, no problem here with the BIOS drive number. My example has 1: in it to switch from the default BIOS drive of hard disk 0. The boot blocks should read the config file on the new drive[,slice,partition] to determine the FreeBSD device name (drive and unit number, but not slice or partition). Leave out 1: from my example. Then booting will not be affected by changes in the BIOS drive number. Bruce To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: How to add a new bootdevice to the new boot code ???
I pass foo from 1:foo(2s1a)kernel in my version of the old boot blocks. And you determine foo how? I type it into the config file or the command line. And you submit that this is an acceptable solution? Of course. The FreeBSD device name won't change (modulo implementation bugs), and even when it does, changing the config file is easier than changing /etc/fstab. Since this entire thread came about due to a device name change, and given that the last major upheaval in this domain was over a similar change, I'd say that was wishful thinking in the least. Note that there is, or should be, no problem here with the BIOS drive number. My example has 1: in it to switch from the default BIOS drive of hard disk 0. The boot blocks should read the config file on the new drive[,slice,partition] to determine the FreeBSD device name (drive and unit number, but not slice or partition). Leave out 1: from my example. Then booting will not be affected by changes in the BIOS drive number. This presupposes that the configuration file is always right, ie. that it correctly describes the location of the disk. This isn't really a valid premise, and in any case does no better than to duplicate the 'last mounted on' field in the filesystem itself. I'm not sold, sorry. This isn't sufficiently automatable, nor does it remove the room for massive user error that I for one fear greatly. -- \\ Sometimes you're ahead, \\ Mike Smith \\ sometimes you're behind. \\ m...@smith.net.au \\ The race is long, and in the \\ msm...@freebsd.org \\ end it's only with yourself. \\ msm...@cdrom.com To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: How to add a new bootdevice to the new boot code ???
And you submit that this is an acceptable solution? Of course. The FreeBSD device name won't change (modulo implementation bugs), and even when it does, changing the config file is easier than changing /etc/fstab. Since this entire thread came about due to a device name change, and given that the last major upheaval in this domain was over a similar change, I'd say that was wishful thinking in the least. Driver name changes are implementation bugs. So are driver numbering changes. The latter are more serious, since you can't work around them by linking files in /dev if the new or old numbering is dynamic. Bruce To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: How to add a new bootdevice to the new boot code ???
In article 199903171205.naa25...@freebsd.dk you wrote: It seems David O'Brien wrote: Boot from an ata disk on major# 30, device name ad, plain and simple. Does this mean ata disks won't come under CAM/da ? Not if I can help it :) It could be done by slamming a translation layer ontop of the existing wd driver or of cause on top of the new I'm doing, but all it adds is overhead, both performance wise and codesize wise. There is nothing that prohibits having both of cause, but it is not a priority for me to add more complexity into the picture before everything else is done. My main complaint so far about the new ATAPI stuff is that it duplicates or lacks (assuming it will be implemented) much of what CAM would have given for almost free: - Interrupt driven configuration - Peripheral driver to device routing - debugging/tracing facilities - an extensible error recovery framework - an understanding of command queuing (also relevant for ATAPI) - understanding of hot plug events - an aplication pass-thru interface The question about translation layers is secondary and I would likely choose to not introduce a translation at all. Issuing pure ATAPI commands to atapi devices at the peripheral driver level is somthing that CAM could easily do. I would probably choose to merge ATAPI functionality into the da driver to avoid duplicated code and to ensure that bug fixes only need to be performed in one place. After all, the machinery for talking to an ATAPI or SCSI disk is very similar (If the disk says it needs to be spun up, spin it up; if we have too many transactions outstanding and fear tag starvation, send an ordered tag; when we close the disk or panic, synchronize its cache to stable media; etc. etc.) even if the command op codes and format are slightly different. But hey, I don't have the time to work on ATAPI. Soren does, so he gets to call the shots. -- Justin To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: How to add a new bootdevice to the new boot code ???
In article 199903171103.naa13...@ceia.nordier.com you wrote: Søren Schmidt wrote: OK, easy enough, this is what I want to do: Boot from an ata disk on major# 30, device name ad, plain and simple. I'd be inclined to handle this outside the boot code, by treating the passed in major# as describing the device rather than specifying the driver. Why not have the boot blocks pass in a device 'name' rather than a major number. If the goal is to ditch major numbers entirely with a properly working DEVFS, then using major numbers in the new boot loader seems to be the wrong way to go. Until DEVFS is a reality, the kernel will still need to perform a name to major number translation, but it should be left up to the kernel. Because there's no way to work out a name either. If I explicitly say: 1:foobar(0,a)/kernel there certainly is a way to work out the name. Perhaps in the autoboot case you'll have to guess, but it would be nice if the current boot mechanism allowed user intervention as a way to boot a kernel with an unknown bdev. All the loader has to go on is the BIOS unit number and the disklabel, the latter of which can't be relied on to be up-to-date (ie. it reflects what the disk was when it was laid out, not what some nominal kernel is going to call it). Well, the disklabel format should be revamped so that we can tag devices in a unique fashion (user's pet name for the partition plus a 128bit random number perhaps). This would allow the boot loader to alway tell the kernel unambiguously how to find the root device. It would also allow us to ensure that the attach order for all devices with a BSD label matched the BIOS probe order. I would also love to be able to mount volumes by the name that I've picked for them rather than by device node too - it would practically eliminate the need for hard wiring of devices. -- Justin To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: How to add a new bootdevice to the new boot code ???
It seems Justin T. Gibbs wrote: In article 199903171205.naa25...@freebsd.dk you wrote: It seems David O'Brien wrote: Boot from an ata disk on major# 30, device name ad, plain and simple. Does this mean ata disks won't come under CAM/da ? Not if I can help it :) It could be done by slamming a translation layer ontop of the existing wd driver or of cause on top of the new I'm doing, but all it adds is overhead, both performance wise and codesize wise. There is nothing that prohibits having both of cause, but it is not a priority for me to add more complexity into the picture before everything else is done. My main complaint so far about the new ATAPI stuff is that it duplicates or lacks (assuming it will be implemented) much of what CAM would have given for almost free: - Interrupt driven configuration That there allready, if we mean the same thing here. - Peripheral driver to device routing Such as ? - debugging/tracing facilities Well, there is a little of that allready, more to come. - an extensible error recovery framework Well, here is room for improvement, I haven't put any real error checking code in there by now, it will just fail and report that for now. This is alpha level code remember. - an understanding of command queuing (also relevant for ATAPI) Hmm, well, yes, but I'm not sure that what ATA/ATAPI has to offer here is comaptible with the CAM framwork. I plan to support tagged queueing on ATA disks though. - understanding of hot plug events This really isn't an issue on ATA/ATAPI devices in most cases, but in the mobile world there is a need for this, but that is already being worked on. We need alot of work in other places in the kernel, before this can be really utilized though. - an aplication pass-thru interface Hmm, what for ?? ATAPI commands could esily be passed through, but I'd like a driver to be in charge here, and besides we allready have drivers for most existing ATAPI HW. The question about translation layers is secondary and I would likely choose to not introduce a translation at all. Issuing pure ATAPI commands to atapi devices at the peripheral driver level is somthing that CAM could easily do. I would probably choose to merge ATAPI functionality into the da driver to avoid duplicated code and to ensure that bug fixes only need to be performed in one place. ATAPI has nothing to do in the da driver, well maybe for ZIP/LS120 drives, but disks are ATA, and that needs translation. After all, the machinery for talking to an ATAPI or SCSI disk is very similar (If the disk says it needs to be spun up, spin it up; if we have too many transactions outstanding and fear tag starvation, send an ordered tag; when we close the disk or panic, synchronize its cache to stable media; etc. etc.) even if the command op codes and format are slightly different. Thats correct, but there is enough differences that it still is a pain. But hey, I don't have the time to work on ATAPI. Soren does, so he gets to call the shots. Right :) -Søren To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: How to add a new bootdevice to the new boot code ???
It seems Justin T. Gibbs wrote: In article 199903171103.naa13...@ceia.nordier.com you wrote: Søren Schmidt wrote: OK, easy enough, this is what I want to do: Boot from an ata disk on major# 30, device name ad, plain and simple. I'd be inclined to handle this outside the boot code, by treating the passed in major# as describing the device rather than specifying the driver. Why not have the boot blocks pass in a device 'name' rather than a major number. If the goal is to ditch major numbers entirely with a properly working DEVFS, then using major numbers in the new boot loader seems to be the wrong way to go. Until DEVFS is a reality, the kernel will still need to perform a name to major number translation, but it should be left up to the kernel. Because there's no way to work out a name either. If I explicitly say: 1:foobar(0,a)/kernel there certainly is a way to work out the name. Perhaps in the autoboot case you'll have to guess, but it would be nice if the current boot mechanism allowed user intervention as a way to boot a kernel with an unknown bdev. YES!! can we please have that ?? -Søren To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: How to add a new bootdevice to the new boot code ???
Søren Schmidt wrote:
It seems Justin T. Gibbs wrote:
Why not have the boot blocks pass in a device 'name' rather than a
major number. If the goal is to ditch major numbers entirely with
a properly working DEVFS, then using major numbers in the new boot
loader seems to be the wrong way to go. Until DEVFS is a reality,
the kernel will still need to perform a name to major number translation,
but it should be left up to the kernel.
Because there's no way to work out a name either.
If I explicitly say:
1:foobar(0,a)/kernel
there certainly is a way to work out the name. Perhaps in the autoboot
case you'll have to guess, but it would be nice if the current boot
mechanism allowed user intervention as a way to boot a kernel with an
unknown bdev.
YES!! can we please have that ??
Until DEVFS is a reality, I think it makes sense to not break
compatibility with the existing boot interface.
What Justin suggests seems good, but why not postpone the big change
till the user has compelling reasons (like a working DEVFS) for
making it, and losing ability to (a) boot 2.x and 3.x kernels; (b)
use his existing bootblocks; and (c) use his existing netboot and
other external (fbsdboot.exe-like) programs?
For the short term, I'd suggest modifying the bootblocks to optionally
accept an arbitrary major# in place of a {wd, da, ad, fd, ...}
string
1:42(0,a)/kernel
since that can easily be accommodated by the existing arguments
passed to the kernel.
While not an optimal solution, this does have the virtue of adding
the ability to boot from any device not specifically provided for,
and without requiring customization of the bootblocks (or any more
work on the kernel than is presently required to add a device
driver).
--
Robert Nordier
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-current in the body of the message
Re: How to add a new bootdevice to the new boot code ???
Bob Willcox wrote: I have an LS-120 and I'd be happy to test the new boot code with it. Bob Thanks very much. I'll contact you and Andrzej when the changes are made. -- Robert Nordier To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: How to add a new bootdevice to the new boot code ???
Soren Schmidt wrote: It seems Justin T. Gibbs wrote: In article 199903171205.naa25...@freebsd.dk you wrote: It seems David O'Brien wrote: Boot from an ata disk on major# 30, device name ad, plain and simple . Does this mean ata disks won't come under CAM/da ? Not if I can help it :) It could be done by slamming a translation layer ontop of the existing wd driver or of cause on top of the new I'm doing, but all it adds is overhead, both performance wise and codesize wise. There is nothing that prohibits having both of cause, but it is not a priority for me to add more complexity into the picture before everything else is done. My main complaint so far about the new ATAPI stuff is that it duplicates or lacks (assuming it will be implemented) much of what CAM would have given for almost free: - Interrupt driven configuration That there allready, if we mean the same thing here. Exactly.. why reinvent it? It seems a little silly to reinvent the other stuff that cam provides that the ata[pi] driver hasn't finished yet. The question about translation layers is secondary and I would likely choose to not introduce a translation at all. Issuing pure ATAPI commands to atapi devices at the peripheral driver level is somthing that CAM could easily do. I would probably choose to merge ATAPI functionality into the da driver to avoid duplicated code and to ensure that bug fixes only need to be performed in one place. ATAPI has nothing to do in the da driver, well maybe for ZIP/LS120 drives, but disks are ATA, and that needs translation. Yes, we know that IDE disks are ATA and not ATAPI, but the cam layer does have a lot of flexibility for dealing with differences even as large as that. You don't really need ``translation'' as such since a lot of the specifics are done by the backend driver and are a black box as far as the higher layers are concerned. You basically get to define the interface between cam and the drivers at your convenience. While the da, cd etc upper level drivers do have scsi specific stuff in them (they are in the scsi subdir after all), they largely deal with generic CCB's (CAM Control Blocks) and send special scsi commands as required. Obviously these would need changing so they can send ATA or ATAPI commands instead. After all, the machinery for talking to an ATAPI or SCSI disk is very similar (If the disk says it needs to be spun up, spin it up; if we have too many transactions outstanding and fear tag starvation, send an ordered tag; when we close the disk or panic, synchronize its cache to stable media; etc. etc.) even if the command op codes and format are slightly different. Thats correct, but there is enough differences that it still is a pain. You shouldn't ever have to translate a scsi CCB or SCSI command code into an ATAPI command or ATA command. A correctly functioning system would be sending the ata/atapi backend the in a form suitable for being used directly. But hey, I don't have the time to work on ATAPI. Soren does, so he gets to call the shots. Right :) Yes. Actually, the biggest problem wouldn't be building an ATA/ATAPI set of frontends and backends around the CAM system, I suspect it would be far harder to finish the generalization of the CAM code. There appear to be a lot of SCSI-specific things lurking in the cam* code... Things like the quirks table referring to T_DIRECT etc (which is from scsi/scsi_all.h) and so on. I half suspect that what Justin had in mind at some point was a set of common code that is either #ifdef'ed or otherwise preprocessed to produce a standalone 'SCSI-CAM' system versus an 'ATA[PI]-CAM' system. This would have the advantage of having all the common code together in one place and shared, while at compile time it built two seperate subsystems that were compiled specifically for the target peripheral bus with definitions to suit each so that translation was never used. -Soren Cheers, -Peter To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: How to add a new bootdevice to the new boot code ???
I half suspect that what Justin had in mind at some point was a set of common code that is either #ifdef'ed or otherwise preprocessed to produce a standalone 'SCSI-CAM' system versus an 'ATA[PI]-CAM' system. I .75 suspect that such a marriage would be caused by the second systems syndrome and carry no tangible benefits at the end of the day. I respect CAM, it seems to work out great. It also looks like sos driver does what it should so far. I don't see much point in merging the two for the benefits suggested so far. In particular I don't want to see sos and justin spend a lot of time haggeling over the issues for the rather meagre benefits cited so far. -- Poul-Henning Kamp FreeBSD coreteam member p...@freebsd.org Real hackers run -current on their laptop. FreeBSD -- It will take a long time before progress goes too far! To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: How to add a new bootdevice to the new boot code ???
I half suspect that what Justin had in mind at some point was a set of common code that is either #ifdef'ed or otherwise preprocessed to produce a standalone 'SCSI-CAM' system versus an 'ATA[PI]-CAM' system. This would have the advantage of having all the common code together in one place and shared, while at compile time it built two seperate subsystems that were compiled specifically for the target peripheral bus with definitions to suit each so that translation was never used. The plan has always been to migrate the SCSI knowledge in the XPT layer into a 'personality' module leaving the generic portions of the CAM XPT intact. The personalities would be compiled in using the atapibus0 and scbus0 keywords in config. I don't think it would be that hard, but it would require time I don't have right now. -- Justin To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: How to add a new bootdevice to the new boot code ???
Søren Schmidt wrote: there certainly is a way to work out the name. Perhaps in the autoboot case you'll have to guess, but it would be nice if the current boot mechanism allowed user intervention as a way to boot a kernel with an unknown bdev. YES!! can we please have that ?? As I said before, loader can pass arbitrary parameters to the kernel. I did not answer to the jab you replied with before because I was waiting for Mike's comments. In any case, all environment strings defined in the loader are (for now) copied so kernel can use them. Pick a name, and DTRT in the kernel. Alternatively, arguments to either boot or load kernel commands are passed on to the kernel. Again, it's just a matter of you using it. The major number passed to the kernel is a product of a lot of guesswork, because the loader has simply not enough information. I have added a bit of code to my version of loader so you can use the variable root_device_major_number to override the major number to be passed to the kernel. I'm inclined to commit it, but I expect strong objections from Mike, who wants the right thing done before we go too far with these hacks. (I can send this patch to you as soon as you answer to my message concerning the problems I'm having with the ad stuff... :) -- Daniel C. Sobral(8-DCS) d...@newsguy.com d...@freebsd.org What happened? It moved, sir! To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: How to add a new bootdevice to the new boot code ???
But hey, I don't have the time to work on ATAPI. Soren does, so he gets to call the shots. Right :) ... so we lose. 8( Soren, please take a little time to understand what Justin is talking about. The parts of CAM that are relevant to you are the queueing support, infrastructure, and the separation between the interface controller and the peripheral driver, something that you've indicated to me several times that you simply don't grasp. Taking advantage of all the code and design that's already been implemented in the CAM framework will make your life easier, not harder. It's not necessary to write a translation layer at all, if such a thing offends your sensibilities. -- \\ Sometimes you're ahead, \\ Mike Smith \\ sometimes you're behind. \\ m...@smith.net.au \\ The race is long, and in the \\ msm...@freebsd.org \\ end it's only with yourself. \\ msm...@cdrom.com To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: How to add a new bootdevice to the new boot code ???
The major number passed to the kernel is a product of a lot of guesswork, because the loader has simply not enough information. I have added a bit of code to my version of loader so you can use the variable root_device_major_number to override the major number to be passed to the kernel. I'm inclined to commit it, but I expect strong objections from Mike, who wants the right thing done before we go too far with these hacks. Correct. I'm currently leaning heavily towards a tunable which can be set to explicitly control the device the root filesystem is loaded from, eg. set kern.rootdev.device=da0s1a However Justin's random number comment speaks back to a technique I was working on earlier, where such a number would be secreted in the disklabel of the disk to be booted. This number would have to be generated in a fairly unique fashion (I planned to use the TOD to try to keep it from wrapping), and it'd then be passed in in the environment or as an argument to the kernel. Bruce really doesn't like the environment, preferring instead arguments to modules. This breaks down as soon as you try to set things automatically (which module needs which arguments?) or load things automatically as a result of dependancies (how do you pass arguments to something that's loaded invisibly?). So in this case the code would set kern.rootdev.brand to the magic number, and the kernel would then search for it. However, there's another technique which would work quite well, and one I'm actually moderately enamoured of (modulo it's ability to confuse the heck out of people). Use the last mounted on field to find and mount filesystems. -- \\ Sometimes you're ahead, \\ Mike Smith \\ sometimes you're behind. \\ m...@smith.net.au \\ The race is long, and in the \\ msm...@freebsd.org \\ end it's only with yourself. \\ msm...@cdrom.com To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: How to add a new bootdevice to the new boot code ???
The major number passed to the kernel is a product of a lot of guesswork, because the loader has simply not enough information. I have added a bit of code to my version of loader so you can use the variable root_device_major_number to override the major number to be passed to the kernel. I'm inclined to commit it, but I expect strong objections from Mike, who wants the right thing done before we go too far with these hacks. Correct. I'm currently leaning heavily towards a tunable which can be set to explicitly control the device the root filesystem is loaded from, eg. set kern.rootdev.device=da0s1a How hard would it be to have /boot/loader get the major number from the filesystem itself? Just have it read the node entry for /dev/$rootdev (or similiar). -- David Cross To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: How to add a new bootdevice to the new boot code ???
Mike Smith wrote: The major number passed to the kernel is a product of a lot of guesswork, because the loader has simply not enough information. I have added a bit of code to my version of loader so you can use the variable root_device_major_number to override the major number to be passed to the kernel. I'm inclined to commit it, but I expect strong objections from Mike, who wants the right thing done before we go too far with these hacks. Correct. On both accounts, I suppose... :-) However Justin's random number comment speaks back to a technique I was working on earlier, where such a number would be secreted in the disklabel of the disk to be booted. This number would have to be generated in a fairly unique fashion (I planned to use the TOD to try to keep it from wrapping), and it'd then be passed in in the environment or as an argument to the kernel. How would that work with netboot or booting from foreign fs, such as FAT? If we restrict ourselves to disklabel-carrying fs, an alternative would be writing the datetime plus a semi-random number (such as time down to ms) on the disklabel of the disk selected, and passing this number to the kernel. [reads what you said again] Unless, of course, that's precisely what you are talking about... :-) I'm not sure if you are talking about a pre-generated label, or one written at boot time. It all rests on the meaning of TOD (tentatively translated as Time Of Day... :). However, there's another technique which would work quite well, and one I'm actually moderately enamoured of (modulo it's ability to confuse the heck out of people). Use the last mounted on field to find and mount filesystems. Again, same objections... :-) -- Daniel C. Sobral(8-DCS) d...@newsguy.com d...@freebsd.org What happened? It moved, sir! To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: How to add a new bootdevice to the new boot code ???
The major number passed to the kernel is a product of a lot of guesswork, because the loader has simply not enough information. I have added a bit of code to my version of loader so you can use the variable root_device_major_number to override the major number to be passed to the kernel. I'm inclined to commit it, but I expect strong objections from Mike, who wants the right thing done before we go too far with these hacks. Correct. I'm currently leaning heavily towards a tunable which can be set to explicitly control the device the root filesystem is loaded from, eg. set kern.rootdev.device=da0s1a How hard would it be to have /boot/loader get the major number from the filesystem itself? Just have it read the node entry for /dev/$rootdev (or similiar). This doesn't solve the BIOS : FreeBSD unit numbering problem, unfortunately, and it would make moving from one driver to another very difficult (you'd have to override the search). It's a neat idea and one I hadn't thought of, but it doesn't solve enough of the problem. -- \\ Sometimes you're ahead, \\ Mike Smith \\ sometimes you're behind. \\ m...@smith.net.au \\ The race is long, and in the \\ msm...@freebsd.org \\ end it's only with yourself. \\ msm...@cdrom.com To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: How to add a new bootdevice to the new boot code ???
My main complaint so far about the new ATAPI stuff is that it duplicates or lacks (assuming it will be implemented) much of what CAM would have given for almost free: - Interrupt driven configuration That there allready, if we mean the same thing here. Right. Its duplicated functionality. - Peripheral driver to device routing Such as ? Such as the ability to have more than one driver share the same device, command generation counts and priority queuing to allow correct 'replay' of overlapped commands when an error occurs, etc. See: http://www.freebsd.org/~gibbs/cam.html for the start of a discussion of these features and why transaction routing was implemented this way. - debugging/tracing facilities Well, there is a little of that allready, more to come. Right. Its duplicated functionality. - an extensible error recovery framework Well, here is room for improvement, I haven't put any real error checking code in there by now, it will just fail and report that for now. This is alpha level code remember. But how will you deal with errors especially when there are overlapped commands? CAM already deals with this in a very clean way. When an error occurs, the controller driver freezes the queue of commands to the erring device, notifies the peripheral driver of the error, and allows the driver to insert error recovery actions before any other commands are ever released to the device. This even allows you to toss back unexecuted but queued commands at the controller level to be reinserted into the transport layer's command queue to ensure proper ordering. This all plays off of the priority features inherent in how transactions are queued. Command queuing was a major factor in why I wrote the CAM code. Solving these issues is not trivial. - an understanding of command queuing (also relevant for ATAPI) Hmm, well, yes, but I'm not sure that what ATA/ATAPI has to offer here is comaptible with the CAM framwork. I plan to support tagged queueing on ATA disks though. CAM only knows that multiple commands may be outstanding at a time and that they must be marked with serial numbers for proper replay when an error occurs. The specifics of how multiple transactions are specified is something that can be completely isolated into the 'personality' module and as a protocol between the peripheral drivers and the controller drivers. - understanding of hot plug events This really isn't an issue on ATA/ATAPI devices in most cases, but in the mobile world there is a need for this, but that is already being worked on. We need alot of work in other places in the kernel, before this can be really utilized though. So why invent a new notification and cleanup strategy when the CAM one has already been developed and tested in the SCSI world? - an aplication pass-thru interface Hmm, what for ?? cdrecord, a userland disk format utility, camcontrol functionality, etc. etc. ATAPI commands could esily be passed through, but I'd like a driver to be in charge here, and besides we allready have drivers for most existing ATAPI HW. The pass-thru driver is in charge in the CAM world. Is this not sufficient? Sure, there needs to be locking primitives so that drivers competing for the same device do not step on each others toes, but this is already specified by CAM and should be only a day or so of effort to implement. ATAPI has nothing to do in the da driver, well maybe for ZIP/LS120 drives, but disks are ATA, and that needs translation. Why does it need translation? Why not simply issue ATA commands right through the CAM Transport layer. Perhaps you use a function table in your peripheral driver to build the right CAM Control Blocks to send for a particular device. Perhaps you have a completely different peripheral driver for ATA and SCSI devices. That is up to the implementor. My choice would be to have one peripheral driver here, but CAM doesn't tie your hands one way or the other. -- Justin To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: How to add a new bootdevice to the new boot code ???
I have an LS-120 and I'd be happy to test the new boot code with it. Bob -- Bob Willcox The man who follows the crowd will usually get no b...@luke.pmr.comfurther than the crowd. The man who walks alone is Austin, TX likely to find himself in places no one has ever been.-- Alan Ashley-Pitt To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: How to add a new bootdevice to the new boot code ???
In article 199903171103.naa13...@ceia.nordier.com you wrote: Søren Schmidt wrote: OK, easy enough, this is what I want to do: Boot from an ata disk on major# 30, device name ad, plain and simple. I'd be inclined to handle this outside the boot code, by treating the passed in major# as describing the device rather than specifying the driver. Why not have the boot blocks pass in a device 'name' rather than a major number. If the goal is to ditch major numbers entirely with a properly working DEVFS, then using major numbers in the new boot loader seems to be the wrong way to go. Until DEVFS is a reality, the kernel will still need to perform a name to major number translation, but it should be left up to the kernel. -- Justin To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: How to add a new bootdevice to the new boot code ???
In article 199903171103.naa13...@ceia.nordier.com you wrote: Søren Schmidt wrote: OK, easy enough, this is what I want to do: Boot from an ata disk on major# 30, device name ad, plain and simple. I'd be inclined to handle this outside the boot code, by treating the passed in major# as describing the device rather than specifying the driver. Why not have the boot blocks pass in a device 'name' rather than a major number. If the goal is to ditch major numbers entirely with a properly working DEVFS, then using major numbers in the new boot loader seems to be the wrong way to go. Until DEVFS is a reality, the kernel will still need to perform a name to major number translation, but it should be left up to the kernel. Because there's no way to work out a name either. All the loader has to go on is the BIOS unit number and the disklabel, the latter of which can't be relied on to be up-to-date (ie. it reflects what the disk was when it was laid out, not what some nominal kernel is going to call it). The *only* way for this to work is for the kernel to hunt for the root device, possibly with some helping hints from the loader. -- \\ Sometimes you're ahead, \\ Mike Smith \\ sometimes you're behind. \\ m...@smith.net.au \\ The race is long, and in the \\ msm...@freebsd.org \\ end it's only with yourself. \\ msm...@cdrom.com To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: How to add a new bootdevice to the new boot code ???
It seems Robert Nordier wrote: If the problem is the bootblocks, why not send a message to Robert Nordier, or if it's loader, to Mike Smith or Daniel Sobral? And say, This is what I want to do, what are we going to do about it? or something similar? OK, easy enough, this is what I want to do: Boot from an ata disk on major# 30, device name ad, plain and simple. As the bootcode is now this wont work. If its as simple as me adding the pair 30 ad somewhere, I'm satisfied, if not, I'm dissapointed :) Hah. You should be reusing the major from 'wd'; there is no other way for this to work, sorry. More eloquently, the only information the loader has is the disk type field from the disklabel, from which it has to decide the major for the root device (this is all historical Vax breakage, but resistance to fixing it has been strong). By picking a random number for the major for your new device, you make the situation much worse than it needs to be; the loader can't tell which ATA driver is in the kernel. -- \\ Sometimes you're ahead, \\ Mike Smith \\ sometimes you're behind. \\ m...@smith.net.au \\ The race is long, and in the \\ msm...@freebsd.org \\ end it's only with yourself. \\ msm...@cdrom.com To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: How to add a new bootdevice to the new boot code ???
This will require relabelling all of one class or the other (new disklabel), or a major overhaul of the way that the root disk is found inside the kernel. IMHO, the latter is where the change needs to happen. SLICE might have made it a little easier, but searching won't actually be all that difficult. Someone want to do the work? I think you are missing the point. We will not chuck the old wd* driver until people have crashed all MFM, RLL, ESDI and !ATA IDE drives. So we WANT to be able to tell the difference... Poul-Henning In message pine.lnx.4.04.9903170447220.17718-100...@feral-gw, Matthew Jacob w rites: I asked Soren just this kind of question, and he declined to answer. I doan geddit... On Wed, 17 Mar 1999, David O'Brien wrote: Boot from an ata disk on major# 30, device name ad, plain and simple. Does this mean ata disks won't come under CAM/da ? If not, can we PLEASE rename SCSI disks back to ``sd''? -- -- David(obr...@nuxi.com -or- obr...@freebsd.org) To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message -- Poul-Henning Kamp FreeBSD coreteam member p...@freebsd.org Real hackers run -current on their laptop. FreeBSD -- It will take a long time before progress goes too far! To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message -- \\ Sometimes you're ahead, \\ Mike Smith \\ sometimes you're behind. \\ m...@smith.net.au \\ The race is long, and in the \\ msm...@freebsd.org \\ end it's only with yourself. \\ msm...@cdrom.com To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: How to add a new bootdevice to the new boot code ???
SLICES, if done right, would make SO many things so much easier. Poul-Henning In message 199903180843.aaa01...@dingo.cdrom.com, Mike Smith writes: This will require relabelling all of one class or the other (new disklabel), or a major overhaul of the way that the root disk is found inside the kernel. IMHO, the latter is where the change needs to happen. SLICE might have made it a little easier, but searching won't actually be all that difficult. Someone want to do the work? I think you are missing the point. We will not chuck the old wd* driver until people have crashed all MFM, RLL, ESDI and !ATA IDE drives. So we WANT to be able to tell the difference... -- Poul-Henning Kamp FreeBSD coreteam member p...@freebsd.org Real hackers run -current on their laptop. FreeBSD -- It will take a long time before progress goes too far! To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: How to add a new bootdevice to the new boot code ???
It seems Robert Nordier wrote: If the problem is the bootblocks, why not send a message to Robert Nordier, or if it's loader, to Mike Smith or Daniel Sobral? And say, This is what I want to do, what are we going to do about it? or something similar? OK, easy enough, this is what I want to do: Boot from an ata disk on major# 30, device name ad, plain and simple. As the bootcode is now this wont work. If its as simple as me adding the pair 30 ad somewhere, I'm satisfied, if not, I'm dissapointed :) -Søren To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: How to add a new bootdevice to the new boot code ???
Søren Schmidt wrote: So here I am with our new boot code and a new device, how the @$ am I supposed to boot from that with the glory new boot blocks, forth and what have we ??? The glory new boot blocks rely on the good old BIOS to boot. Anything else is a chickenegg problem. -- Daniel C. Sobral(8-DCS) d...@newsguy.com d...@freebsd.org What happened? It moved, sir! To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: How to add a new bootdevice to the new boot code ???
Søren Schmidt wrote: OK, easy enough, this is what I want to do: Boot from an ata disk on major# 30, device name ad, plain and simple. I'd be inclined to handle this outside the boot code, by treating the passed in major# as describing the device rather than specifying the driver. The point about the boot code is it is deliberately intended to be usable when completely out of sync with any actual kernel it is booting. (I expect to be able to use 2.0 bootblocks with 4.0, and also that loader will be able to boot a 2.0 kernel.) I assume at some stage that some stage the new driver will take over completely, and the older driver will disappear. Before that, as people grow accustomed to thinking ad rather than wd, it will probably make sense for the boot code to accept (say) 0:ad(0,a)boot/loader rather than 0:wd(0,a)boot/loader However, I'd *still* expect it to pass a major# of 0 rather than 30. Why? Because a 2.0 kernel knows only 0. And if a 5.0 kernel knows only 30, it is -- at least -- in a position to know what 0 meant, and simply substitute one for the other (under the influence of a kernel configuration option, if necessary). As an example of the kind of reasoning that goes into the above, consider the case of booting from CD-ROM. If the boot image used is that of a floppy, the major# used is 2; if the boot image uses is that of a hard disk (quite probably a old 20M MFM 615x4x17 hard disk), the major# used is 0. So in both cases, the major# doesn't relate to what was booted from, and may not even describe the underlying technology correctly. As the bootcode is now this wont work. If its as simple as me adding the pair 30 ad somewhere, I'm satisfied, if not, I'm dissapointed :) -- Robert Nordier To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: How to add a new bootdevice to the new boot code ???
It seems Robert Nordier wrote: Søren Schmidt wrote: OK, easy enough, this is what I want to do: Boot from an ata disk on major# 30, device name ad, plain and simple. I'd be inclined to handle this outside the boot code, by treating the passed in major# as describing the device rather than specifying the driver. The point about the boot code is it is deliberately intended to be usable when completely out of sync with any actual kernel it is booting. (I expect to be able to use 2.0 bootblocks with 4.0, and also that loader will be able to boot a 2.0 kernel.) I assume at some stage that some stage the new driver will take over completely, and the older driver will disappear. Before that, as people grow accustomed to thinking ad rather than wd, it will Not likely, as long as we need support for MFM/RLL/ESDI disk, wd.c will stay around. probably make sense for the boot code to accept (say) 0:ad(0,a)boot/loader rather than 0:wd(0,a)boot/loader That would be nice, could I please have that ?? However, I'd *still* expect it to pass a major# of 0 rather than 30. Why? Because a 2.0 kernel knows only 0. And if a 5.0 kernel knows only 30, it is -- at least -- in a position to know what 0 meant, and simply substitute one for the other (under the influence of a kernel configuration option, if necessary). Hmm, wd should give 0 and ad should give 30, no AI please :) I've tried fooling the driver to just use the 0 number, but mount blows up, complaing that mounted root is different from specified root... -Søren To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: How to add a new bootdevice to the new boot code ???
Boot from an ata disk on major# 30, device name ad, plain and simple. Does this mean ata disks won't come under CAM/da ? If not, can we PLEASE rename SCSI disks back to ``sd''? -- -- David(obr...@nuxi.com -or- obr...@freebsd.org) To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: How to add a new bootdevice to the new boot code ???
It seems David O'Brien wrote: Boot from an ata disk on major# 30, device name ad, plain and simple. Does this mean ata disks won't come under CAM/da ? Not if I can help it :) It could be done by slamming a translation layer ontop of the existing wd driver or of cause on top of the new I'm doing, but all it adds is overhead, both performance wise and codesize wise. There is nothing that prohibits having both of cause, but it is not a priority for me to add more complexity into the picture before everything else is done. If not, can we PLEASE rename SCSI disks back to ``sd''? No objections from me. But why, it will only confuse users once again... -Søren To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: How to add a new bootdevice to the new boot code ???
Boot from an ata disk on major# 30, device name ad, plain and simple. Does this mean ata disks won't come under CAM/da ? If not, can we PLEASE rename SCSI disks back to ``sd''? Agreed. I see no justification for the sd - da change if the ATA disks won't (eventually) be included. Steinar Haug, Nethelp consulting, sth...@nethelp.no To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: How to add a new bootdevice to the new boot code ???
I asked Soren just this kind of question, and he declined to answer. I doan geddit... On Wed, 17 Mar 1999, David O'Brien wrote: Boot from an ata disk on major# 30, device name ad, plain and simple. Does this mean ata disks won't come under CAM/da ? If not, can we PLEASE rename SCSI disks back to ``sd''? -- -- David(obr...@nuxi.com -or- obr...@freebsd.org) To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: How to add a new bootdevice to the new boot code ???
I assume at some stage that some stage the new driver will take over completely, and the older driver will disappear. Before that, as people grow accustomed to thinking ad rather than wd, it will Not likely, as long as we need support for MFM/RLL/ESDI disk, wd.c will stay around. probably make sense for the boot code to accept (say) 0:ad(0,a)boot/loader rather than 0:wd(0,a)boot/loader That would be nice, could I please have that ?? OK, I'll add it to the bootblocks. Incidentally, while I'm in there and thinking about it, I'd quite like to fix the boot code to boot from LS-120 drives at the same time. So if anyone has one of these, and wouldn't mind spending some time running a few bits of test code, I'd appreciate it. However, I'd *still* expect it to pass a major# of 0 rather than 30. Why? Because a 2.0 kernel knows only 0. And if a 5.0 kernel knows only 30, it is -- at least -- in a position to know what 0 meant, and simply substitute one for the other (under the influence of a kernel configuration option, if necessary). Hmm, wd should give 0 and ad should give 30, no AI please :) I wasn't actually thinking at all along the lines of smart code at all: #ifdef FORCE_FOO if (foo == 0) foo = 30; #endif The administrator or operator is still entirely in control; the only difference is in what part of the code the control is exercised. AFAICS, adopting the separate wd and ad route entails the following: Update your bootblocks. Add a /boot.config statement like 0:ad(0,a) to make use of the driver the default. Failure to boot if you inadvertently specify wd out of habit, or if you specify ad when booting an earlier system. So we're introducing three points with good potential for failure. In contrast, the kernel configuration route requires commenting or uncommenting a single statement. -- Robert Nordier To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: How to add a new bootdevice to the new boot code ???
It seems Matthew Jacob wrote: I asked Soren just this kind of question, and he declined to answer. I doan geddit... WHAT ?? I replied with this: #From sos Wed Mar 17 08:51:14 1999 #Subject: Re: How to add a new bootdevice to the new boot code ??? #In-Reply-To: pine.lnx.4.04.9903161510480.12815-100...@feral-gw from Matthew Jacob at Mar 16, 1999 3:11: 1 pm #To: mja...@feral.com #Date: Wed, 17 Mar 1999 08:51:14 +0100 (CET) # #It seems Matthew Jacob wrote: # #Is this a rant or a request for information? # #I could be both :), but basically I want to know what should be #done to have it boot from a new major#, in this case 30 the #new ata driver. But from a look at the code it seems that this #might be alot more work than it should be Geddit now ?? At least try to read to the end of your mailbox, before accusing me for ignorance, thankyou! -Søren To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: How to add a new bootdevice to the new boot code ???
It seems Robert Nordier wrote: OK, I'll add it to the bootblocks. Incidentally, while I'm in there and thinking about it, I'd quite like to fix the boot code to boot from LS-120 drives at the same time. So if anyone has one of these, and wouldn't mind spending some time running a few bits of test code, I'd appreciate it. I have a ZIP if that can help you ?? However, I'd *still* expect it to pass a major# of 0 rather than 30. Why? Because a 2.0 kernel knows only 0. And if a 5.0 kernel knows only 30, it is -- at least -- in a position to know what 0 meant, and simply substitute one for the other (under the influence of a kernel configuration option, if necessary). Hmm, wd should give 0 and ad should give 30, no AI please :) I wasn't actually thinking at all along the lines of smart code at all: #ifdef FORCE_FOO if (foo == 0) foo = 30; #endif Well, that breaks somewhere else, as the mount code is clever enough to look at the name of the driver in this case ad which doesn't match the specified #0 ie wd. I kindof tried this by having my driver put itself in both the wd ad majors in the table, but that doesn't work, because the mount stuff gets confused on the root name somehow, and fails to mount root because the names dont match... AFAICS, adopting the separate wd and ad route entails the following: Update your bootblocks. Add a /boot.config statement like 0:ad(0,a) to make use of the driver the default. Failure to boot if you inadvertently specify wd out of habit, or if you specify ad when booting an earlier system. So we're introducing three points with good potential for failure. Well, what else can we do as long as we potentially need both drivers in the kernel. I'm pretty sure that if I kill of wd.c et all, there will be screams of bloody murder again... been there done that :) In contrast, the kernel configuration route requires commenting or uncommenting a single statement. But that doesn't work, at least as the mount code behaves now. At any rate, any solution that makes it possible to boot with a new driver without me having to call it wd something all over the place is acceptable to me... -Søren To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: How to add a new bootdevice to the new boot code ???
I think you are missing the point. We will not chuck the old wd* driver until people have crashed all MFM, RLL, ESDI and !ATA IDE drives. So we WANT to be able to tell the difference... Poul-Henning In message pine.lnx.4.04.9903170447220.17718-100...@feral-gw, Matthew Jacob w rites: I asked Soren just this kind of question, and he declined to answer. I doan geddit... On Wed, 17 Mar 1999, David O'Brien wrote: Boot from an ata disk on major# 30, device name ad, plain and simple. Does this mean ata disks won't come under CAM/da ? If not, can we PLEASE rename SCSI disks back to ``sd''? -- -- David(obr...@nuxi.com -or- obr...@freebsd.org) To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message -- Poul-Henning Kamp FreeBSD coreteam member p...@freebsd.org Real hackers run -current on their laptop. FreeBSD -- It will take a long time before progress goes too far! To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: How to add a new bootdevice to the new boot code ???
Incidentally, while I'm in there and thinking about it, I'd quite
like to fix the boot code to boot from LS-120 drives at the same
time. So if anyone has one of these, and wouldn't mind spending
some time running a few bits of test code, I'd appreciate it.
I have a ZIP if that can help you ??
Thanks. AFAIK, the essential difference is that the LS-120 needs
to be treated (in the boot code) like a floppy, whereas the ZIP
should be treated like a hard disk. But we need to accommodate
both, so I'd be glad if you'd test the changes, once I've done
them.
#ifdef FORCE_FOO
if (foo == 0)
foo = 30;
#endif
Well, that breaks somewhere else, as the mount code is clever enough
to look at the name of the driver in this case ad which doesn't
match the specified #0 ie wd.
I kindof tried this by having my driver put itself in both the
wd ad majors in the table, but that doesn't work, because the mount
stuff gets confused on the root name somehow, and fails to mount
root because the names dont match...
The arguments passed from the boot code to the kernel are
howto, bootdev, res1, res2, res3, bootinfop
where
howto is an int containing RB_* bitflags (sys/reboot.h) which
represent the boot options like -c, -v, etc.
bootdev is an int put together using the MAKEBOOTDEV macro
(sys/reboot.h) from the major#, unit#, slice#, and partition#
of the boot device.
res1 through res3 are reserved/ignored.
bootinfop is a pointer to a bootinfo structure
(machine/bootinfo.h) which contains an assortments of parameters,
but none relating directly to the boot device driver (bi_bios_dev
is for /boot/loader's benefit).
So the *only* relevant info passed by the boot code is the major#.
And if we force a change in the major# (for the sake of discussion,
in the section of src/sys/i386/i386/locore.s that already has
compatibility code for dealing with legacy bootblocks -- though
I'm not saying that is the best place for it), we've done all we
*can* do in the boot code, within the framework as it exists.
So whether we add {da, 30} to a lookup table in boot2, or use the
FORCE_FOO approach, the results will be identical.
At any rate, any solution that makes it possible to boot with
a new driver without me having to call it wd something all
over the place is acceptable to me...
Anyway, I take a look at both approaches, probably later today,
and send you some diffs, hopefully relating to each way of doing
things.
--
Robert Nordier
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-current in the body of the message
Re: How to add a new bootdevice to the new boot code ???
On Wed, 17 Mar 1999, Robert Nordier wrote: Incidentally, while I'm in there and thinking about it, I'd quite like to fix the boot code to boot from LS-120 drives at the same time. So if anyone has one of these, and wouldn't mind spending some time running a few bits of test code, I'd appreciate it. I can do that when I'm back in Poland (i.e. after Cebit). Andrzej Bialecki // ab...@webgiro.com WebGiro AB, Sweden (http://www.webgiro.com) // --- // -- FreeBSD: The Power to Serve. http://www.freebsd.org // --- Small Embedded FreeBSD: http://www.freebsd.org/~picobsd/ To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: How to add a new bootdevice to the new boot code ???
Søren Schmidt wrote: Well, that breaks somewhere else, as the mount code is clever enough to look at the name of the driver in this case ad which doesn't match the specified #0 ie wd. I kindof tried this by having my driver put itself in both the wd ad majors in the table, but that doesn't work, because the mount stuff gets confused on the root name somehow, and fails to mount root because the names dont match... I know you most certainly could not possibly have forgotten that, but it's the kind of thing that just *must* be mentioned... /etc/fstab? -- Daniel C. Sobral(8-DCS) d...@newsguy.com d...@freebsd.org What happened? It moved, sir! To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: How to add a new bootdevice to the new boot code ???
Poul-Henning Kamp wrote: I think you are missing the point. We will not chuck the old wd* driver until people have crashed all MFM, RLL, ESDI and !ATA IDE drives. So we WANT to be able to tell the difference... The point here is just naming. Right now, we have: wd0, ... ad0, ... da0, ... People are asking for: wd0, ... da0, ... Ie, join ad and da namespaces. -- Daniel C. Sobral(8-DCS) d...@newsguy.com d...@freebsd.org What happened? It moved, sir! To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: How to add a new bootdevice to the new boot code ???
Andrzej Bialecki wrote: On Wed, 17 Mar 1999, Robert Nordier wrote: Incidentally, while I'm in there and thinking about it, I'd quite like to fix the boot code to boot from LS-120 drives at the same time. So if anyone has one of these, and wouldn't mind spending some time running a few bits of test code, I'd appreciate it. I can do that when I'm back in Poland (i.e. after Cebit). Andrzej Bialecki Thanks! I'll take you up on that. -- Robert Nordier To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: How to add a new bootdevice to the new boot code ???
sth...@nethelp.no wrote: Amen. Does this mean ata disks won't come under CAM/da ? If not, can we PLEASE rename SCSI disks back to ``sd''? Agreed. I see no justification for the sd - da change if the ATA disks won't (eventually) be included. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: How to add a new bootdevice to the new boot code ???
In message 36eff0f0.9c57e...@newsguy.com, Daniel C. Sobral writes: Poul-Henning Kamp wrote: I think you are missing the point. We will not chuck the old wd* driver until people have crashed all MFM, RLL, ESDI and !ATA IDE drives. So we WANT to be able to tell the difference... The point here is just naming. Right now, we have: wd0, ... ad0, ... da0, ... People are asking for: wd0, ... da0, ... Ie, join ad and da namespaces. If you want to join anything, go directly to disk%d instead. -- Poul-Henning Kamp FreeBSD coreteam member p...@freebsd.org Real hackers run -current on their laptop. FreeBSD -- It will take a long time before progress goes too far! To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: How to add a new bootdevice to the new boot code ???
It seems Daniel C. Sobral wrote: Søren Schmidt wrote: Well, that breaks somewhere else, as the mount code is clever enough to look at the name of the driver in this case ad which doesn't match the specified #0 ie wd. I kindof tried this by having my driver put itself in both the wd ad majors in the table, but that doesn't work, because the mount stuff gets confused on the root name somehow, and fails to mount root because the names dont match... I know you most certainly could not possibly have forgotten that, but it's the kind of thing that just *must* be mentioned... /etc/fstab? Nope thats not it, been there too :) -Søren To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: How to add a new bootdevice to the new boot code ???
Søren Schmidt wrote: It seems Daniel C. Sobral wrote: Søren Schmidt wrote: Well, that breaks somewhere else, as the mount code is clever enough to look at the name of the driver in this case ad which doesn't match the specified #0 ie wd. I kindof tried this by having my driver put itself in both the wd ad majors in the table, but that doesn't work, because the mount stuff gets confused on the root name somehow, and fails to mount root because the names dont match... I know you most certainly could not possibly have forgotten that, but it's the kind of thing that just *must* be mentioned... /etc/fstab? Nope thats not it, been there too :) Ok, I have a clue... bootdev can be different from rootdev. I don't know where this makes a difference, but it makes... :-) Meanwhile, edit sys/boot/i386/libi386/biosdisk.c and change WDMAJOR to 30. If that doesn't help, the problem must be elsewhere. Also, make sure you don't have any root_disk_unit or num_ide_disks set. -- Daniel C. Sobral(8-DCS) d...@newsguy.com d...@freebsd.org What happened? It moved, sir! To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: How to add a new bootdevice to the new boot code ???
People are asking for: wd0, ... da0, ... Ie, join ad and da namespaces. If you want to join anything, go directly to disk%d instead. But that is not the deal that was presented to us when we had to endure the gratuitous sd-da name change. The whole justification was a single device name for disks (and what ever else is direct access). -- -- David(obr...@nuxi.com -or- obr...@freebsd.org) To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: How to add a new bootdevice to the new boot code ???
In message 19990317113918.b39...@relay.nuxi.com, David O'Brien writes: People are asking for: wd0, ... da0, ... Ie, join ad and da namespaces. If you want to join anything, go directly to disk%d instead. But that is not the deal that was presented to us when we had to endure the gratuitous sd-da name change. The whole justification was a single device name for disks (and what ever else is direct access). The fact that Justin promised that ATA ***Could*** use CAM, didn't seem to imply to me that it would, unless somebody wrote code for it. That didn't happen. -- Poul-Henning Kamp FreeBSD coreteam member p...@freebsd.org Real hackers run -current on their laptop. FreeBSD -- It will take a long time before progress goes too far! To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: How to add a new bootdevice to the new boot code ???
On Wed, 17 Mar 1999 11:39:18 -0800, David O'Brien obr...@nuxi.com said: But that is not the deal that was presented to us when we had to endure the gratuitous sd-da name change. The whole justification was a single device name for disks (and what ever else is direct access). No, that was not the justification for the name change. The justification (Justinfication?) was that in SCSI terminology, these things -- not all of which are disks -- are called ``direct access'' devices. Similarly, `sa' is ``sequential access''. ATAPI had nothing whatsoever to do with it. -GAWollman -- Garrett A. Wollman | O Siem / We are all family / O Siem / We're all the same woll...@lcs.mit.edu | O Siem / The fires of freedom Opinions not those of| Dance in the burning flame MIT, LCS, CRS, or NSA| - Susan Aglukark and Chad Irschick To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: How to add a new bootdevice to the new boot code ???
It seems David O'Brien wrote: People are asking for: wd0, ... da0, ... Ie, join ad and da namespaces. If you want to join anything, go directly to disk%d instead. But that is not the deal that was presented to us when we had to endure the gratuitous sd-da name change. The whole justification was a single device name for disks (and what ever else is direct access). Yes on the SCSI busses, nothing more nothing less Direct Access is the SCSI term for, among others, disks... It was _mentioned_ that ATAPI devices was semilar to SCSI devices and that it _could_ be done through CAM, there was NO promise or anything back when, and there still isn't. ATA disks which this is about, is pretty far way from the CAM/SCSI world, but again a translation layer could be added inbetween. But given the situation that most ATA/ATAPI systems are used in, I belive that our user base will be more interested in max performance instead.. So the sd - da etc namechange has nothing to do with what I'm about to do. I simply ask for the support for booting from any BDEV, and that has not been dealt with in the new boot stuff. Thats what I'm complaining about, dont tell me it wasn't done because all disk like device should be named da, thats too naive to be belived :) -Søren To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: How to add a new bootdevice to the new boot code ???
Daniel C. Sobral wrote: Søren Schmidt wrote: I know you most certainly could not possibly have forgotten that, but it's the kind of thing that just *must* be mentioned... /etc/fstab? Nope thats not it, been there too :) Ok, I have a clue... bootdev can be different from rootdev. I don't know where this makes a difference, but it makes... :-) In loader, you can have a default device (currdev), but load from a different device (loaddev) and pass a third device to the kernel (rootdev). In the simple case of booting from ad0, all the default settings would be correct, though. Also, make sure you don't have any root_disk_unit or num_ide_disks set. A num_ide_disks setting is used only where the major# indicates a SCSI device, so it wouldn't affect things. -- Robert Nordier To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: How to add a new bootdevice to the new boot code ???
No, that was not the justification for the name change. The justification (Justinfication?) was that in SCSI terminology, these things -- not all of which are disks -- are called ``direct access'' devices. Similarly, `sa' is ``sequential access''. Then why do we still have ``cd''? Isn't a CDROM a direct access device? Last time I used my, I didn't have to read sector 1 before reading sector 9893. -- -- David(obr...@nuxi.com -or- obr...@freebsd.org) To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: How to add a new bootdevice to the new boot code ???
According to David E . O'Brien: If not, can we PLEASE rename SCSI disks back to ``sd''? I'm tempted to agree. Many people I know who are upgrading to 3.* are somewhat pissed off by the renaming, even if it is in the release notes. They don't see any good reason for it... -- Ollivier ROBERT -=- FreeBSD: The Power to Serve! -=- robe...@keltia.freenix.fr FreeBSD keltia.freenix.fr 4.0-CURRENT #70: Sat Feb 27 09:43:08 CET 1999 To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: How to add a new bootdevice to the new boot code ???
Ollivier Robert wrote... According to David E . O'Brien: If not, can we PLEASE rename SCSI disks back to ``sd''? I'm tempted to agree. Many people I know who are upgrading to 3.* are somewhat pissed off by the renaming, even if it is in the release notes. They don't see any good reason for it... Do we have to go over this again and again? It'll be worse if we change back. And it's not like anyone had to upgrade their fstab -- all of the sd devices still work, since the major number is the same. So there's not a lot of room for complaint here. (Yeah, I'm sure someone will start squawking about it right about now.) So, just let it rest. There are lots of more pressing things to worry about. Ken -- Kenneth Merry k...@plutotech.com To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: How to add a new bootdevice to the new boot code ???
On Wed, 17 Mar 1999, S?ren Schmidt wrote: It seems Robert Nordier wrote: OK, I'll add it to the bootblocks. Incidentally, while I'm in there and thinking about it, I'd quite like to fix the boot code to boot from LS-120 drives at the same time. So if anyone has one of these, and wouldn't mind spending some time running a few bits of test code, I'd appreciate it. I have a ZIP if that can help you ?? However, I'd *still* expect it to pass a major# of 0 rather than 30. Why? Because a 2.0 kernel knows only 0. And if a 5.0 kernel knows only 30, it is -- at least -- in a position to know what 0 meant, and simply substitute one for the other (under the influence of a kernel configuration option, if necessary). Hmm, wd should give 0 and ad should give 30, no AI please :) I wasn't actually thinking at all along the lines of smart code at all: #ifdef FORCE_FOO if (foo == 0) foo = 30; #endif Well, that breaks somewhere else, as the mount code is clever enough to look at the name of the driver in this case ad which doesn't match the specified #0 ie wd. I kindof tried this by having my driver put itself in both the wd ad majors in the table, but that doesn't work, because the mount stuff gets confused on the root name somehow, and fails to mount root because the names dont match... AFAICS, adopting the separate wd and ad route entails the following: Update your bootblocks. Add a /boot.config statement like 0:ad(0,a) to make use of the driver the default. Failure to boot if you inadvertently specify wd out of habit, or if you specify ad when booting an earlier system. So we're introducing three points with good potential for failure. Well, what else can we do as long as we potentially need both drivers in the kernel. I'm pretty sure that if I kill of wd.c et all, there will be screams of bloody murder again... been there done that :) Well, since the new ATA doesn't work with my LS-120 yet nor support DMA... ;) I want to see the LS-120 working, so where would I send it to if you were to work on its driver? :) In contrast, the kernel configuration route requires commenting or uncommenting a single statement. But that doesn't work, at least as the mount code behaves now. At any rate, any solution that makes it possible to boot with a new driver without me having to call it wd something all over the place is acceptable to me... -S?ren To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message Brian Feldman_ __ ___ ___ ___ gr...@unixhelp.org _ __ ___ | _ ) __| \ http://www.freebsd.org/ _ __ ___ | _ \__ \ |) | FreeBSD: The Power to Serve! _ __ ___ _ |___/___/___/ To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: How to add a new bootdevice to the new boot code ???
And it's not like anyone had to upgrade their fstab -- all of the sd devices still work, since the major number is the same. So there's not a lot of room for complaint here. Only if sysinstall goes back to creating the /dev/sd* devices and matching fstab w/``sd''. -- -- David(obr...@nuxi.com -or- obr...@freebsd.org) To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: How to add a new bootdevice to the new boot code ???
David O'Brien wrote... And it's not like anyone had to upgrade their fstab -- all of the sd devices still work, since the major number is the same. So there's not a lot of room for complaint here. Only if sysinstall goes back to creating the /dev/sd* devices and matching fstab w/``sd''. What does that have to do anything? If sysinstall is doing the work, the user doesn't have to. Ken -- Kenneth Merry k...@plutotech.com To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
How to add a new bootdevice to the new boot code ???
So here I am with our new boot code and a new device, how the @$ am I supposed to boot from that with the glory new boot blocks, forth and what have we ??? If my suspicion is right, the glory fades pretty damn fast... -Søren To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: How to add a new bootdevice to the new boot code ???
Søren Schmidt wrote: So here I am with our new boot code and a new device, how the @$ am I supposed to boot from that with the glory new boot blocks, forth and what have we ??? If my suspicion is right, the glory fades pretty damn fast... This is a bit on the incoherent side, Soren. :-) If the problem is the bootblocks, why not send a message to Robert Nordier, or if it's loader, to Mike Smith or Daniel Sobral? And say, This is what I want to do, what are we going to do about it? or something similar? -- Robert Nordier To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
