Re: ATAPI and ATAPI_STATIC with the new ATA* driver?
Kelly Yancey wrote: have to support ATA devices too. He also suggested a more universal device name like drv0, drv1, drv2, etc rather than deliniating between whether the drive is ATA or SCSI...I also think that is a good idea as I don't see any good reason an application should care whether the drive is ATA or SCSI, as long as the functionality is provided does it matter how? The boot code might be distressed... :-) -- Daniel C. Sobral(8-DCS) d...@newsguy.com d...@freebsd.org FreeBSD is Yoda, Linux is Luke Skywalker. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: ATAPI and ATAPI_STATIC with the new ATA* driver?
The only thing that bit me was that I used wd0 and wd2 with the older driver, whereas the newer driver automatically decided to use ad0 and ad1. This is expected behaviour, but it's something for other weenies to watch out for. :-) This breakage was announced :-). Besides, it is not even a breakage. It finally got _unbroken_. :-) It is breakage, and should be fixed. It's only just now been fixed. The convention on the i386 platform is to pack unit numbers; the 'wd' driver was our sole exception (the BIOS and the SCSI code both pack unit numbers). Since it's now consistent with everything else, it should stay as-is. Wiring ATAPI units down is of limited utility, but should probably be supported for people that like those silly removable drive sleds. -- \\ 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: ATAPI and ATAPI_STATIC with the new ATA* driver?
Date: Thu, 04 Mar 1999 02:53:09 +0900 From: Daniel C. Sobral d...@newsguy.com Irrespective of all the valid reasons to allow for wiring (but not mandate), static drive numbering is not BIOS compatible (thus, not DOS compatible). This violates POLA. I'm at least as much against POLA violations as anyone... but the real POLA violation I see is the apparent dependence on the BIOS, since it is controlled by a process external to the UNIX environment. DOS compatability is not one of my concerns; I have difficulty imagining a universe in which it would become one. Indeed, if someone were to claim DOS compatibility for something, I would have no way of knowing what that was supposed to imply, since I'm nearly completely unfamiliar with DOS. (The few times I've tried to use it, I would get different results from the same actions on my part, so I gave up.) DOS compatibility is irrelevant. What is at issue here is _firmware_ compatability. -- \\ 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: ATAPI and ATAPI_STATIC with the new ATA* driver?
It's been like this with SCSI disks since day #1. I don't see it ever having been quite the disaster of epic proportions that you make it out to be. When a boot fails with something like /dev/rwd2s1g: Device not configured, how long will it take you to figure out that it was actually wd1 that didn't probe and what is now visible as wd1 is what you used to know as wd2? If the disks are identical, you have to look carefully at the boot messages. If that isn't a POLA violation, what is? Talk about bike shelter material. -- \\ 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: ATAPI and ATAPI_STATIC with the new ATA* driver?
Kelly Yancey wrote: have to support ATA devices too. He also suggested a more universal device name like drv0, drv1, drv2, etc rather than deliniating between whether the drive is ATA or SCSI...I also think that is a good idea as I don't see any good reason an application should care whether the drive is ATA or SCSI, as long as the functionality is provided does it matter how? The boot code might be distressed... :-) Not as long as the ordering matched the BIOS ordering. The boot code would love it. -- \\ 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: ATAPI and ATAPI_STATIC with the new ATA* driver?
Sheldon Hearn sheld...@iafrica.com writes: I'm not sure I understand what real-world frustrations people are having here. Is this thread the product of reactionary criticism, or are there real examples of situations in which there are serious disadvantages to the way Soren has things working? So far, you seem to have received replies arguing for convenience, which isn't the only valid reason for static device numbering. When a boot fails with something like /dev/rwd2s1g: Device not configured, how long will it take you to figure out that it was actually wd1 that didn't probe and what is now visible as wd1 is what you used to know as wd2? If the disks are identical, you have to look carefully at the boot messages. If that isn't a POLA violation, what is? What about if your /etc/fstab only checks/mounts partitions on wd0/wd1, and /etc/rc doesn't fail because of the missing wd2? Instead, you have partitions in unexpected places... Oh and of course if you aren't pedantic about partitioning conventions and have a non-'b' swap partition or a 'b'-partition used as a filesystem, you might be swapping onto a filesystem...even if the fsck fails and drops you into single user mode. Disks can fail to probe, even when they aren't permanently broken, e.g. because of failure to spin up. Fixed numbering isn't merely a convenience for those who add and remove devices routinely. Changing the default behavior from a safer alternative to a more dangerous one might not be a good thing. Of course dangerous numbering is the default for SCSI devices, as well... Perhaps it's reasonable to expect people who don't know what they're doing to only have one or two disks. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
RE: ATAPI and ATAPI_STATIC with the new ATA* driver?
It's really frustrating if I add new drive (anywhere on the busses) and other drives change their numbers - it's good base for big troubles (infinite changing /etc/fstab and so on). Fair enough. But in real life, you don't add a new drive anywhere on the busses. You know _exactly_ which controller you're attaching the drive to, and you know whether the drive is the master or the slave. This information is enough for you to figure out _exactly_ where in the probing the drive will be spotted and numbered. I'm not sure I understand what real-world frustrations people are having here. Is this thread the product of reactionary criticism, or are there real examples of situations in which there are serious disadvantages to the way Soren has things working? Ciao, Sheldon. I think you are absolutely right. On all of our servers here, all running various versions of FreeBSD, we've been using SCSI drives for years, which as we all know have the same problem that ATA drives have now. The only difference is that with SCSI devices, a mechanism exists to wire-down device names to devices. The only real problem that exists with the new ATA driver is that it doesn't support the same wiring-down for ATA devices. I don't remember who suggested it a couple of days ago, but I thought it was a good idea: to simply extend the wiring-down scheme that we already have to support ATA devices too. He also suggested a more universal device name like drv0, drv1, drv2, etc rather than deliniating between whether the drive is ATA or SCSI...I also think that is a good idea as I don't see any good reason an application should care whether the drive is ATA or SCSI, as long as the functionality is provided does it matter how? Great job Soren, the new drivers are great (although DMA support would make them extra cool :) ) Kelly ~kby...@posi.net~ To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
RE: ATAPI and ATAPI_STATIC with the new ATA* driver?
I don't remember who suggested it a couple of days ago, but I thought it was a good idea: to simply extend the wiring-down scheme that we already have to support ATA devices too. He also suggested a more universal device name like drv0, drv1, drv2, etc rather than deliniating between whether the drive is ATA or SCSI...I also think that is a good idea as I don't see any good reason an application should care whether the drive is ATA or SCSI, as long as the functionality is provided does it matter how? Agreed. I had always assumed that this was part of the reason for the name change sd - da, namely that da would (eventually) cover ATA disks also. 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: ATAPI and ATAPI_STATIC with the new ATA* driver?
The only thing that bit me was that I used wd0 and wd2 with the older driver, whereas the newer driver automatically decided to use ad0 and ad1. This is expected behaviour, but it's something for other weenies to watch out for. :-) This breakage was announced :-). Besides, it is not even a breakage. It finally got _unbroken_. :-) It is breakage, and should be fixed. It isn't breakage when everybody else assigns identities to ATA disks sequentially, irespective of how much other gunk (Ie: CD, Tape) is present on the busses.
Re: ATAPI and ATAPI_STATIC with the new ATA* driver?
On Wed, 03 Mar 1999 13:13:10 +0100, Cejka Rudolf wrote: It's really frustrating if I add new drive (anywhere on the busses) and other drives change their numbers - it's good base for big troubles (infinite changing /etc/fstab and so on). Fair enough. But in real life, you don't add a new drive anywhere on the busses. You know _exactly_ which controller you're attaching the drive to, and you know whether the drive is the master or the slave. This information is enough for you to figure out _exactly_ where in the probing the drive will be spotted and numbered. I'm not sure I understand what real-world frustrations people are having here. Is this thread the product of reactionary criticism, or are there real examples of situations in which there are serious disadvantages to the way Soren has things working? Ciao, Sheldon. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
RE: ATAPI and ATAPI_STATIC with the new ATA* driver?
-Original Message- From: Sheldon Hearn [SMTP:sheld...@iafrica.com] Sent: Wednesday, March 03, 1999 1:40 PM To: Cejka Rudolf Cc: freebsd-current@freebsd.org; s...@freebsd.dk Subject: Re: ATAPI and ATAPI_STATIC with the new ATA* driver? I'm not sure I understand what real-world frustrations people are having here. Is this thread the product of reactionary criticism, or are there real examples of situations in which there are serious disadvantages to the way Soren has things working? [ML] Well, it's for those people who plug a drive occasionally into a computer. They don't want other drives moved around. This is the situation that the external SCSI disc case owners live with for years now, and was the reason device wiring was introduced for SCSI devices. Soeren said that the same mechanism could be added for atapi devices as well (yet better, extended to include the atapi devices as well). He just doesn't currently have time to do it right now. /Marino Ciao, Sheldon. 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: ATAPI and ATAPI_STATIC with the new ATA* driver?
On Wed, 03 Mar 1999 14:07:22 +0100, Ladavac Marino wrote: [ML] Well, it's for those people who plug a drive occasionally into a computer. They don't want other drives moved around. Thanks for the feedback. Jeremy Lea also provided in private mail quite a detailed example of why device wiring for the ATA* driver is desirable. Guess the answer for now is that people who can't live without statically numbered drives continue to use the older IDE driver or mail Soren diffs for adding device wiring support. :-) Thanks again, Sheldon. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: ATAPI and ATAPI_STATIC with the new ATA* driver?
It seems Sheldon Hearn wrote: Guess the answer for now is that people who can't live without statically numbered drives continue to use the older IDE driver or mail Soren diffs for adding device wiring support. :-) Well, well, don't panic :) I'll provide an option in the next commit round that gives the same numbering as the old driver... This will have to do for now, as getting ATAPI drives fixed also is a bit more tricky (hint changer devices). If all goes well, it will be there tonight (CET), as I also have a LS120/ZIP driver ready, plus alot of other little fixes... -Søren To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: ATAPI and ATAPI_STATIC with the new ATA* driver?
On Wed, 3 Mar 1999, S?ren Schmidt wrote: It seems Sheldon Hearn wrote: Guess the answer for now is that people who can't live without statically numbered drives continue to use the older IDE driver or mail Soren diffs for adding device wiring support. :-) Well, well, don't panic :) I'll provide an option in the next commit round that gives the same numbering as the old driver... This will have to do for now, as getting ATAPI drives fixed also is a bit more tricky (hint changer devices). If all goes well, it will be there tonight (CET), as I also have a LS120/ZIP driver ready, plus alot of other little fixes... GLEE FORM=CHILDISH Yahoo!! Whoop!! Go Soren, go! /GLEE -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: ATAPI and ATAPI_STATIC with the new ATA* driver?
Cejka Rudolf wrote: What was bad with old static drive numbering? Irrespective of all the valid reasons to allow for wiring (but not mandate), static drive numbering is not BIOS compatible (thus, not DOS compatible). This violates POLA. -- Daniel C. Sobral(8-DCS) d...@newsguy.com d...@freebsd.org FreeBSD is Yoda, Linux is Luke Skywalker. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: ATAPI and ATAPI_STATIC with the new ATA* driver?
Date: Thu, 04 Mar 1999 02:53:09 +0900 From: Daniel C. Sobral d...@newsguy.com Irrespective of all the valid reasons to allow for wiring (but not mandate), static drive numbering is not BIOS compatible (thus, not DOS compatible). This violates POLA. I'm at least as much against POLA violations as anyone... but the real POLA violation I see is the apparent dependence on the BIOS, since it is controlled by a process external to the UNIX environment. DOS compatability is not one of my concerns; I have difficulty imagining a universe in which it would become one. Indeed, if someone were to claim DOS compatibility for something, I would have no way of knowing what that was supposed to imply, since I'm nearly completely unfamiliar with DOS. (The few times I've tried to use it, I would get different results from the same actions on my part, so I gave up.) And yes, I realize that neither my experiences nor perspective may be representative of anyone else. david -- David Wolfskill UNIX System Administrator d...@whistle.comvoice: (650) 577-7158 pager: (650) 371-4621 To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: ATAPI and ATAPI_STATIC with the new ATA* driver?
David Wolfskill wrote: Irrespective of all the valid reasons to allow for wiring (but not mandate), static drive numbering is not BIOS compatible (thus, not DOS compatible). This violates POLA. I'm at least as much against POLA violations as anyone... but the real POLA violation I see is the apparent dependence on the BIOS, since it is controlled by a process external to the UNIX environment. It is not a matter of dependence (which, obviously, does not exist). Is a matter of: 1) Doing the same as everyone else (meaning, here, the most common background for newbies; if one is not a newbie, POLA doesn't comes into play for this particular issue). 2) Having the OS see disks in the same way/ordering as the program that boot it does, *unless explicitly instructed otherwise*. DOS compatability is not one of my concerns; I have difficulty imagining a universe in which it would become one. Indeed, if someone were to claim DOS compatibility for something, I would have no way of knowing what that was supposed to imply, since I'm nearly completely unfamiliar with DOS. (The few times I've tried to use it, I would get different results from the same actions on my part, so I gave up.) :-) And yes, I realize that neither my experiences nor perspective may be representative of anyone else. Which, unfortunately, plays a part in POLA. -- Daniel C. Sobral(8-DCS) d...@newsguy.com d...@freebsd.org FreeBSD is Yoda, Linux is Luke Skywalker. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: ATAPI and ATAPI_STATIC with the new ATA* driver?
On 03-Mar-99 Sheldon Hearn wrote: I'm not sure I understand what real-world frustrations people are having here. Is this thread the product of reactionary criticism, or are there real examples of situations in which there are serious disadvantages to the way Soren has things working? I don't think its too terrible to have devices made in probe order, but it would be *nice* to have it if you are fiddling and removing/inserting a device and rebooting (I've done this debugging stuff) and IMHO it would suck having to edit fstab everytime. OK, so its not gonna happen very often, *but* it would be nice to have :) --- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au The nice thing about standards is that there are so many of them to choose from. -- Andrew Tanenbaum To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
ATAPI and ATAPI_STATIC with the new ATA* driver?
On Mon, 01 Mar 1999 13:19:20 PST, Søren Schmidt wrote: # for a PCI only system (most modern machines) controller ata0 device atadisk0# ATA disks device atapicd0# ATAPI CDROM's device atapist0# ATAPI tapes Hi Soren, Am I correct in assuming that we can toast ATAPI and ATAPI_STATIC in our kernel configs if we're using your new driver? Ciao, Sheldon. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: ATAPI and ATAPI_STATIC with the new ATA* driver?
It seems Sheldon Hearn wrote: On Mon, 01 Mar 1999 13:19:20 PST, Søren Schmidt wrote: # for a PCI only system (most modern machines) controllerata0 deviceatadisk0# ATA disks deviceatapicd0# ATAPI CDROM's deviceatapist0# ATAPI tapes Hi Soren, Am I correct in assuming that we can toast ATAPI and ATAPI_STATIC in our kernel configs if we're using your new driver? Yes, they are not used by the new driver, it only needs the above lines in config, depending on how many subdrivers you want of cause. -Søren To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: ATAPI and ATAPI_STATIC with the new ATA* driver?
On Tue, 02 Mar 1999 10:49:17 +0100, Søren Schmidt wrote: Yes, they are not used by the new driver, it only needs the above lines in config, depending on how many subdrivers you want of cause. Excellent. :-) The only thing that bit me was that I used wd0 and wd2 with the older driver, whereas the newer driver automatically decided to use ad0 and ad1. This is expected behaviour, but it's something for other weenies to watch out for. :-) Sadly, cdcontrol still doesn't work with the newer driver and my braindead Creative Labs Infra36 CDROM drive. My older quad speed HITACHI still works. I noticed that the error message has changed, though. I used to get cdcontrol play cdcontrol: Input/output error Now I get cdcontrol play cdcontrol: Unknown error: 84 I guess no amount of programmer cleverness is going to get around crap hardware. Still, if you want me to try things with the hardware I've got, I'm happy to try. I'd offer you shell access, but South African connectivity isn't the best. :-) acd1: CREATIVECD2421E/1.04 CDROM drive at ata1 as slave acd1: drive speed 112 - 4133KB/sec, 240KB cache acd1: supported read types: CD-DA acd1: Audio: play, 255 volume levels acd1: Mechanism: ejectable tray acd1: Medium: no/blank disc inside, unlocked Ciao, Sheldon. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: ATAPI and ATAPI_STATIC with the new ATA* driver?
It seems Sheldon Hearn wrote: The only thing that bit me was that I used wd0 and wd2 with the older driver, whereas the newer driver automatically decided to use ad0 and ad1. This is expected behaviour, but it's something for other weenies to watch out for. :-) I warned about that in the anounce :) Sadly, cdcontrol still doesn't work with the newer driver and my braindead Creative Labs Infra36 CDROM drive. My older quad speed HITACHI still works. I noticed that the error message has changed, though. I used to get cdcontrol play cdcontrol: Input/output error Now I get cdcontrol play cdcontrol: Unknown error: 84 Hmm, you could try to enable the debug in atapi-all.c atapi-cd.c and mail me the output of that. The unknown error is because the new driver doesn't translate the atapi errors to errno errors yet. I guess no amount of programmer cleverness is going to get around crap hardware. Still, if you want me to try things with the hardware I've got, I'm happy to try. I'd offer you shell access, but South African connectivity isn't the best. :-) :) lets see what we can do before that, I still have alot of little things I need to get in there, this is just to get people banging on the driver to get feedback early in the development cycle. -Søren To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: ATAPI and ATAPI_STATIC with the new ATA* driver?
The only thing that bit me was that I used wd0 and wd2 with the older driver, whereas the newer driver automatically decided to use ad0 and ad1. This is expected behaviour, but it's something for other weenies to watch out for. :-) This breakage was announced :-). Bruce To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: ATAPI and ATAPI_STATIC with the new ATA* driver?
On Tue, 02 Mar 1999 22:26:50 +1100, Bruce Evans wrote: This breakage was announced :-). My only defense is my use of the phrase other weenies in my original mail. ;-) Ciao, Sheldon. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: ATAPI and ATAPI_STATIC with the new ATA* driver?
Sheldon Hearn wrote: On Tue, 02 Mar 1999 10:49:17 +0100, Søren Schmidt wrote: Yes, they are not used by the new driver, it only needs the above lines in config, depending on how many subdrivers you want of cause. Excellent. :-) The only thing that bit me was that I used wd0 and wd2 with the older driver, whereas the newer driver automatically decided to use ad0 and ad1. This is expected behaviour, but it's something for other weenies to watch out for. :-) Is/will there be a way to wire the devices down like you can with SCSI devices? To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: ATAPI and ATAPI_STATIC with the new ATA* driver?
Bruce Evans wrote: The only thing that bit me was that I used wd0 and wd2 with the older driver, whereas the newer driver automatically decided to use ad0 and ad1. This is expected behaviour, but it's something for other weenies to watch out for. :-) This breakage was announced :-). Besides, it is not even a breakage. It finally got _unbroken_. :-) -- Daniel C. Sobral(8-DCS) d...@newsguy.com d...@freebsd.org FreeBSD is Yoda, Linux is Luke Skywalker. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: ATAPI and ATAPI_STATIC with the new ATA* driver?
The only thing that bit me was that I used wd0 and wd2 with the older driver, whereas the newer driver automatically decided to use ad0 and ad1. This is expected behaviour, but it's something for other weenies to watch out for. :-) This breakage was announced :-). Besides, it is not even a breakage. It finally got _unbroken_. :-) It is breakage, and should be fixed. Bruce To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: ATAPI and ATAPI_STATIC with the new ATA* driver?
On Wed, 03 Mar 1999 00:53:37 +0900, Daniel C. Sobral wrote: The only thing that bit me was that I used wd0 and wd2 with the older driver, whereas the newer driver automatically decided to use ad0 and ad1. [...] Besides, it is not even a breakage. It finally got _unbroken_. :-) All I'm trying to say (and I agree that I really should learn to say exactly what I mean on this mailing list) is that this is something about which much song and dance will need to be made when the driver makes it into STABLE. I didn't read the announcement carefully enough. Nevertheless, I think it'll be useful for any future announcement to STABLE to say something like: Remember that disks are now numbered in the sequence in which they are found (as under the SCSI system), not in absolute positions as they were with the old system. For example, if you had wd0 and wd2 but no wd1, you'll now have wd0 and wd1. Watch out for this, because you may need to change your /etc/fstab and create appropriate entriess in /dev/ before booting your new kernel. I think that Soren's announcement was perfectly adequate for the intended audience, but I do believe that something like the suggestion above will help other weenies like me even more. :-) Ciao, Sheldon. Microsoft Windows NT - now sporting cutting-edge features cribbed from operating systems that only introduced them 20 years ago. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: ATAPI and ATAPI_STATIC with the new ATA* driver?
In message 199903021646.daa26...@godzilla.zeta.org.au, Bruce Evans writes: The only thing that bit me was that I used wd0 and wd2 with the older driver, whereas the newer driver automatically decided to use ad0 and ad1. This is expected behaviour, but it's something for other weenies to watch out for. :-) This breakage was announced :-). Besides, it is not even a breakage. It finally got _unbroken_. :-) It is breakage, and should be fixed. It isn't breakage when everybody else assigns identities to ATA disks sequentially, irespective of how much other gunk (Ie: CD, Tape) is present on the busses. -- 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: ATAPI and ATAPI_STATIC with the new ATA* driver?
This breakage was announced :-). Besides, it is not even a breakage. It finally got _unbroken_. :-) It is breakage, and should be fixed. It isn't breakage when everybody else assigns identities to ATA disks sequentially, irespective of how much other gunk (Ie: CD, Tape) is present on the busses. Linux doesn't. It IDE cdroms to IDE drive minor numbers, e.g., hda = 1st controller, IDE drive hdb = 1st controller, IDE cdrom hdc = 2nd controller, IDE drive The sequencing of controllers isn't unique, so the breakage doesn't even work around the problem of mapping BIOS drive numbers to FreeBSD device names except in simple cases. Bruce To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: ATAPI and ATAPI_STATIC with the new ATA* driver?
In message 199903021812.faa32...@godzilla.zeta.org.au, Bruce Evans writes: This breakage was announced :-). Besides, it is not even a breakage. It finally got _unbroken_. :-) It is breakage, and should be fixed. It isn't breakage when everybody else assigns identities to ATA disks sequentially, irespective of how much other gunk (Ie: CD, Tape) is present on the busses. Linux doesn't. Linux isn't everybody else. -- 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: ATAPI and ATAPI_STATIC with the new ATA* driver?
It isn't breakage when everybody else assigns identities to ATA disks
sequentially, irespective of how much other gunk (Ie: CD, Tape) is
present on the busses.
Linux doesn't.
Linux isn't everybody else.
Neither is { everybody else } - { linux }.
Bruce
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-current in the body of the message
