On Sat, 13 Sep 2003 08:29:18 +0200, Jens Axboe <[email protected]> wrote:
>> Actually with 2.6, you no longer need ide-scsi. You'll need to upgrade
>> your cdrecord tools and probably your burning GUI, if you use one. I've
>> been burning that way for several months now. (I'm using xcdroast,
>> though I need to start it with "-n" since I'm using cdrecord 2.01a18.)
>> This actually works better for me than ide-scsi as for some reason it
>> uses less CPU.
>
>That's because it _is_ faster. It contains no silly memory allocations
>for the buffer and data copying in the kernel, the data is mapped from
>the user buffer and DMA'ed directly from there. It also uses DMA where
>ide-scsi wont.
That begs the question: why won't ide-scsi do DMA?
I understand you'd rather see it disappear (:->) but since I use
it for other ATAPI devices as well, I'd like to see it maintained
and fully operational. Having DMA in ide-scsi would be nice.
(And the concept of using a SCSI API to ATA devices is in itself
not broken, even if the implementation has some problems.)
/Mikael
On Saturday 13 of September 2003 13:01, Mikael Pettersson wrote:
> On Sat, 13 Sep 2003 08:29:18 +0200, Jens Axboe <[email protected]> wrote:
> >> Actually with 2.6, you no longer need ide-scsi. You'll need to upgrade
> >> your cdrecord tools and probably your burning GUI, if you use one. I've
> >> been burning that way for several months now. (I'm using xcdroast,
> >> though I need to start it with "-n" since I'm using cdrecord 2.01a18.)
> >> This actually works better for me than ide-scsi as for some reason it
> >> uses less CPU.
> >
> >That's because it _is_ faster. It contains no silly memory allocations
> >for the buffer and data copying in the kernel, the data is mapped from
> >the user buffer and DMA'ed directly from there. It also uses DMA where
> >ide-scsi wont.
>
> That begs the question: why won't ide-scsi do DMA?
> I understand you'd rather see it disappear (:->) but since I use
> it for other ATAPI devices as well, I'd like to see it maintained
> and fully operational. Having DMA in ide-scsi would be nice.
ide-scsi maintainer position is available :-).
> (And the concept of using a SCSI API to ATA devices is in itself
> not broken, even if the implementation has some problems.)
It is not broken short-term, however it is broken long-term.
> /Mikael
On Sad, 2003-09-13 at 12:01, Mikael Pettersson wrote:
> That begs the question: why won't ide-scsi do DMA?
Because nobody added it. Its that simple
> I understand you'd rather see it disappear (:->) but since I use
> it for other ATAPI devices as well, I'd like to see it maintained
> and fully operational. Having DMA in ide-scsi would be nice.
I don't see it vanishing either - people abuse IDE (especially SATA) for
weird stuff like high end scanners which want to use ide-scsi for sg. I
agree with Bart about ide-scsi for disks. For tape ide-tape isnt good
enough for newer stuff but that could be fixed either way
> (And the concept of using a SCSI API to ATA devices is in itself
> not broken, even if the implementation has some problems.)
ATA drives don't generally talk ATAPI as well so you have protocol
stuff. For Serial ATA that is what the current SATA code everyone is
using does and each SATA vendor has followed the same path because our
existing PATA code
In 2.7 the SCSI layer split can get finished so it seperates "scsi the
protocol" from "queueing engine and handling for an intelligent
controller".
Right now its not too bad - error handling is entirely pluggable for
example.
On Sat, Sep 13, 2003 at 07:04:36PM +0100, Alan Cox wrote:
> In 2.7 the SCSI layer split can get finished so it seperates "scsi the
> protocol" from "queueing engine and handling for an intelligent
> controller".
Yep, this is exactly my plan. And exactly why libata must use
the SCSI layer in 2.4 and 2.6, and in 2.7 use the "queueing engine ..."
stuff that you describe.
There are a lot of pieces in the SCSI layer that I want to move "up" to
the block layer in 2.7: ->queuecommand "queue one" callback and loop
(Jens has code for this already), error handling thread helper code,
low-level device driver registration structure[1], personality code
(disk, cdrom, tape, ....), support for host controllers which may have
host _or_ device (or both!) TCQ limits, and on and on.
That's a ton of code, and IMO it's not feasible to (a) recreate it
for 2.6 libata, or (b) do the "move up" in 2.6.0-testX and change ide,
scsi, block, ... drivers to use the new helpers and new structure.
Changes are too big this late in the 2.6 game.
As of next week (I'm presenting this at Intel Developer Forum), libata
will support "AHCI", Intel's next generation SATA controller. Each PCI
device supports up to 32 SATA ports (one SATA device each). Each port
supports up to 32 outstanding ATA commands (i.e. 32 tags), including a
64-bit-DMA-capable scatter-gather table. The S/G doesn't have the silly
64K segment boundary worries, either.
Promise hardware is similar -- up to 10 "packets" (taskfiles) can be
queued per host... not per device. SCSI layer handles this with just a
few knob-turns.
For 2.6, libata (unfortunately) requires the SCSI layer for ATA
devices, and libata drives real hardware that noone else can drive.
For 2.7, when all this code "moves up" -- basically adding a bunch of
helper functions to the block layer -- libata won't need to treat ATA
devices as SCSI devices.
Some developers have rightfully pointed out that disks going from
/dev/hdX to /dev/sdX might create some user confusion. This hasn't been
the case in practice. Partly because LABEL= is fairly prevalent, and
partly because libata is used for "only SATA" scenarios, which is by
definition new hardware.
On to /dev/disk...
Another interesting part of this "moving up" is that I want to unify the
personality code. The various tape, cdrom, and disk modules for ide,
scsi, and others are quite similar. And if you look closer at today's
block layer, you see that already everything is designed around "struct
request". So I envision a more top-down structure, with helper
functions and callbacks combining to form: /dev/disk, /dev/cdrom,
/dev/tape, ...
The generic "disk" personality code would take care of allocating block
device major/minors (i.e. register_blkdev duties), and generating
requests. Existing ->prep_rq helpers will fill in the specific details.
Subsystem-specfic ioctls can be delivered as REQ_SPECIAL.
cdrom, tape, and friends follow a similar pattern.
"What about /dev/hda!" Answer: a simple remapping block device, which
simulates /dev/hdXX or /dev/sdXX, by remapping all requests to
/dev/diskXX.
So the next time you hear me say "libata must wait for 2.7 to ditch SCSI"
this is what I mean ;-) These aren't unachieveable goals, either. It's
mostly code shuffling. This code mostly already exists today.
Jeff
[1] low-level driver registers a set of callbacks, which are
either implemented in the driver itself (cciss, cpqarray) or mostly
library-based helper functions (ATA or SCSI).
On Sat, Sep 13, 2003 at 03:01:31PM -0400, Jeff Garzik wrote:
> Oh, and I'm pondering the best way to deliver out-of-bang ATA taskfiles
lol. That would be "out-of-band".
Oh, and I'm pondering the best way to deliver out-of-bang ATA taskfiles
and SCSI cdbs to a device. (for the uninitiated, this is lower level
than block devices / cdrom devices / etc.)
... AF_BLOCK is not out of the question ;-)
Jeff
On Saturday 13 of September 2003 20:49, Jeff Garzik wrote:
> On Sat, Sep 13, 2003 at 07:04:36PM +0100, Alan Cox wrote:
> > In 2.7 the SCSI layer split can get finished so it seperates "scsi the
> > protocol" from "queueing engine and handling for an intelligent
> > controller".
>
> Yep, this is exactly my plan. And exactly why libata must use
> the SCSI layer in 2.4 and 2.6, and in 2.7 use the "queueing engine ..."
> stuff that you describe.
>
> There are a lot of pieces in the SCSI layer that I want to move "up" to
> the block layer in 2.7: ->queuecommand "queue one" callback and loop
> (Jens has code for this already), error handling thread helper code,
> low-level device driver registration structure[1], personality code
> (disk, cdrom, tape, ....), support for host controllers which may have
> host _or_ device (or both!) TCQ limits, and on and on.
>
> That's a ton of code, and IMO it's not feasible to (a) recreate it
> for 2.6 libata, or (b) do the "move up" in 2.6.0-testX and change ide,
> scsi, block, ... drivers to use the new helpers and new structure.
> Changes are too big this late in the 2.6 game.
>
> As of next week (I'm presenting this at Intel Developer Forum), libata
> will support "AHCI", Intel's next generation SATA controller. Each PCI
> device supports up to 32 SATA ports (one SATA device each). Each port
> supports up to 32 outstanding ATA commands (i.e. 32 tags), including a
> 64-bit-DMA-capable scatter-gather table. The S/G doesn't have the silly
> 64K segment boundary worries, either.
>
> Promise hardware is similar -- up to 10 "packets" (taskfiles) can be
> queued per host... not per device. SCSI layer handles this with just a
> few knob-turns.
>
> For 2.6, libata (unfortunately) requires the SCSI layer for ATA
> devices, and libata drives real hardware that noone else can drive.
>
> For 2.7, when all this code "moves up" -- basically adding a bunch of
> helper functions to the block layer -- libata won't need to treat ATA
> devices as SCSI devices.
s/ATA/SATA/
ATA and SATA will still need their own driver(s) aware of driver-model,
sysfs, ATA quirks/tuning etc. I am working on this part currently, so you can
concentrate on new, sexy SATA, leaving all dirty, legacy ATA for me.
For all other stuff described in your mail I can only say: HELL YEAH!.
> Some developers have rightfully pointed out that disks going from
> /dev/hdX to /dev/sdX might create some user confusion. This hasn't been
> the case in practice. Partly because LABEL= is fairly prevalent, and
> partly because libata is used for "only SATA" scenarios, which is by
> definition new hardware.
>
>
> On to /dev/disk...
> Another interesting part of this "moving up" is that I want to unify the
> personality code. The various tape, cdrom, and disk modules for ide,
> scsi, and others are quite similar. And if you look closer at today's
> block layer, you see that already everything is designed around "struct
> request". So I envision a more top-down structure, with helper
> functions and callbacks combining to form: /dev/disk, /dev/cdrom,
> /dev/tape, ...
>
> The generic "disk" personality code would take care of allocating block
> device major/minors (i.e. register_blkdev duties), and generating
> requests. Existing ->prep_rq helpers will fill in the specific details.
> Subsystem-specfic ioctls can be delivered as REQ_SPECIAL.
>
> cdrom, tape, and friends follow a similar pattern.
>
> "What about /dev/hda!" Answer: a simple remapping block device, which
> simulates /dev/hdXX or /dev/sdXX, by remapping all requests to
> /dev/diskXX.
>
> So the next time you hear me say "libata must wait for 2.7 to ditch SCSI"
> this is what I mean ;-) These aren't unachieveable goals, either. It's
> mostly code shuffling. This code mostly already exists today.
>
> Jeff
>
>
> [1] low-level driver registers a set of callbacks, which are
> either implemented in the driver itself (cciss, cpqarray) or mostly
> library-based helper functions (ATA or SCSI).
On Sat, Sep 13, 2003 at 09:24:05PM +0200, Bartlomiej Zolnierkiewicz wrote:
> On Saturday 13 of September 2003 20:49, Jeff Garzik wrote:
> > For 2.6, libata (unfortunately) requires the SCSI layer for ATA
> > devices, and libata drives real hardware that noone else can drive.
> >
> > For 2.7, when all this code "moves up" -- basically adding a bunch of
> > helper functions to the block layer -- libata won't need to treat ATA
> > devices as SCSI devices.
>
> s/ATA/SATA/
>
> ATA and SATA will still need their own driver(s) aware of driver-model,
> sysfs, ATA quirks/tuning etc.
Agreed. Though I think some of your work in sysfs area can be made
common.
> I am working on this part currently, so you can
> concentrate on new, sexy SATA, leaving all dirty, legacy ATA for me.
Sounds good to me ;-) Though I'll definitely want to work together with
you on several issues in 2.7...
> For all other stuff described in your mail I can only say: HELL YEAH!.
;-)
Jeff
Oh, and I'm pondering the best way to deliver out-of-bang ATA taskfiles
and SCSI cdbs to a device. (for the uninitiated, this is lower level
than block devices / cdrom devices / etc.)
... AF_BLOCK is not out of the question ;-)
Well, I think the main issue to doing this is one of layering. What
SAM-3 did for SCSI was essentially give us a 3 layer stack which the
kernel represents as the upper, the mid and the lower layers (Note,
these layers are subdividable too).
For SCSI commands, queuecommand() is a natural handoff point from the
mid to lower layer representing a pure scsi command with no transport
dependent details.
For ATA, a task file does contain transport dependent knowledge, thus it
should enter the stack at a slightly lower level (and a level which the
current SCSI model doesn't even represent).
Thus, the two ways of approaching this would seem to be either to derive
somehow a way of removing the transport dependence from the taskfile (a
sort of Task CDB for ATA), or redo the driver model stack to subdivide
the current low level drivers correctly. I think the latter will
probably be more productive, particularly if the subdivision is made
optional (and thus wouldn't affect most of the drivers currently in the
tree). Even in SCSI, there are certain register based SCSI Parallel
cards that would benefit from being driven at the same level as a task
file.
James
On Sat, Sep 13, 2003 at 03:16:09PM -0500, James Bottomley wrote:
>
> Oh, and I'm pondering the best way to deliver out-of-bang ATA taskfiles
> and SCSI cdbs to a device. (for the uninitiated, this is lower level
> than block devices / cdrom devices / etc.)
>
> ... AF_BLOCK is not out of the question ;-)
>
>
> Well, I think the main issue to doing this is one of layering. What
> SAM-3 did for SCSI was essentially give us a 3 layer stack which the
> kernel represents as the upper, the mid and the lower layers (Note,
> these layers are subdividable too).
>
> For SCSI commands, queuecommand() is a natural handoff point from the
> mid to lower layer representing a pure scsi command with no transport
> dependent details.
>
> For ATA, a task file does contain transport dependent knowledge, thus it
> should enter the stack at a slightly lower level (and a level which the
> current SCSI model doesn't even represent).
This is a good point, and I admit I don't have a good response.
On one hand, the current kernel interface presented to userland is
the same for ATA and SCSI: "an ioctl, which sends packet to device"
So from the standpoint of the userland ABI, that rebuts layering to
a certain extent. We even have ioctls in today's ATA layer to send
SCSI CDBs to ATA devices! ;-)
So from that angle, it all looks like a packet to me.
Or struct request, shall I say. or skb. after a while they are all the
same to me...
> Thus, the two ways of approaching this would seem to be either to derive
> somehow a way of removing the transport dependence from the taskfile (a
> sort of Task CDB for ATA), or redo the driver model stack to subdivide
> the current low level drivers correctly. I think the latter will
> probably be more productive, particularly if the subdivision is made
> optional (and thus wouldn't affect most of the drivers currently in the
> tree). Even in SCSI, there are certain register based SCSI Parallel
> cards that would benefit from being driven at the same level as a task
> file.
"the latter" is what I'm shooting for, with /dev/disk. Or maybe
a better moniker is storage API. I think that parallels a theme I am
pursuing in 2.7:
Make the low-level driver interface for ATA devices, RAID devices
like cciss, etc. look strikingly similar to the SCSI low-level driver
interface. At that point we call it the "storage LLD interface".
This would IMO encompass the low-level driver subdivision you describe.
Ideally an ata/scsi/raid driver shouldn't be doing much more than
h/w queue processing, and some hooks for unusual events like power
management or h/w-specific device enumeration.
Overall I'd like to get "low level drivers" at pretty much the same
level. ATA and SCSI drivers would be fairly small, with a lot of their
functionality handled by helper functions. RAID drivers would be
largers.
Another thorny tangent to throw out there:
IMO, we need to move users from a [probe-]order-based device and bus
enumeration to some system based on unique ids. I'm of the opinion
that _both_ block devices and filesystems need some sort of GUID.
Luckily, a lot of blkdevs/fs's are already there.
If you look at current usage out there, order isn't _terribly_ important
given today's tools (such as LABEL=). More important IMO is figuring
out which spindle is your boot disk, and which is your root disk.
Red Hat handles root disks by doing LABEL= from initrd. But discovering
the boot disk is still largely an unsolved problem AFAIK...
Jeff
On Sat, 2003-09-13 at 22:27, Jeff Garzik wrote:
> IMO, we need to move users from a [probe-]order-based device and bus
> enumeration to some system based on unique ids. I'm of the opinion
> that _both_ block devices and filesystems need some sort of GUID.
> Luckily, a lot of blkdevs/fs's are already there.
>
> If you look at current usage out there, order isn't _terribly_ important
> given today's tools (such as LABEL=). More important IMO is figuring
> out which spindle is your boot disk, and which is your root disk.
> Red Hat handles root disks by doing LABEL= from initrd. But discovering
> the boot disk is still largely an unsolved problem AFAIK...
LABEL= is so broken that I immediately remove it from all my redhat
systems. It is not unique at all. As soon as you plug another system
disk into your system at boot time all hell breaks loose. At least it
could have a random number in it or something.
If you need to know your bootdisk (why?) why not just get the bootloader
to tell you?
Justin
On Sul, 2003-09-14 at 12:15, Justin Cormack wrote:
> LABEL= is so broken that I immediately remove it from all my redhat
> systems. It is not unique at all. As soon as you plug another system
> disk into your system at boot time all hell breaks loose. At least it
> could have a random number in it or something.
You can use UUID's for labels too if you prefer. I normally write a
host string into my labels. What I actually want is mount by label to
develop an rpc service so I can mount by label and if the disk is in
another box NFS it 8)
> If you need to know your bootdisk (why?) why not just get the bootloader
> to tell you?
The bootloader doesn't know. It has a bios concept of the boot device
which is really hard if at all possible to translate without things like
EDD.
On Sat, Sep 13, 2003 at 05:27:23PM -0400, Jeff Garzik wrote:
> IMO, we need to move users from a [probe-]order-based device and bus
> enumeration to some system based on unique ids. I'm of the opinion
> that _both_ block devices and filesystems need some sort of GUID.
> Luckily, a lot of blkdevs/fs's are already there.
>
> If you look at current usage out there, order isn't _terribly_ important
> given today's tools (such as LABEL=). More important IMO is figuring
> out which spindle is your boot disk, and which is your root disk.
> Red Hat handles root disks by doing LABEL= from initrd. But discovering
> the boot disk is still largely an unsolved problem AFAIK...
Such things are infinitely difficult.
Moreover, great care is needed - one has to define precisely what it
is this GUID is supposed to be an ID of.
(Is it the ZIP drive? Or is it the ZIP disk?
The 2.4 USB code is broken because it remembers a GUID and thinks that
identical GUID implies identical disk.)
I have a handful of CF/SM cardreaders.
Some of them have no form of ID. Others have an ID.
Then one can insert a CF or SM card into the reader.
Some of these cards have an ID. Some have not.
On the card one usually finds a FAT filesystem.
There may be a label. Or there may not be.
This describes a 3-level situation.
I have also 4-level situations, where the reader is filled with
one of four auxiliary adapters (each with an own ID) and the
adapter then get a CF/SM/SD/... card.
So, yes, we love IDs. And we can always provide them ourselves
as label or UUID or so in the filesystem.
But finding an unformatted unlabeled disk is difficult.
Andries
Alan Cox wrote:
> You can use UUID's for labels too if you prefer. I normally write a
> host string into my labels. What I actually want is mount by label to
> develop an rpc service so I can mount by label and if the disk is in
> another box NFS it 8)
Sounds yummy! When can we start testing it? <G>
On Sun, Sep 14, 2003 at 12:15:27PM +0100, Justin Cormack wrote:
> LABEL= is so broken that I immediately remove it from all my redhat
> systems. It is not unique at all. As soon as you plug another system
> disk into your system at boot time all hell breaks loose. At least it
> could have a random number in it or something.
I do not understand your complaint.
It is you who assigns the label. You can choose whatever label you fancy.
Include any random strings you like.
> If you need to know your bootdisk (why?) why not just get the bootloader
> to tell you?
I am not quite sure why anybody would like to know what the bootdisk was.
The rootdisk, yes, that we need. But the bootdisk?
Finding it is nontrivial in general. Letting the bootloader tell us
is also nontrivial.
Justin Cormack wrote:
> LABEL= is so broken that I immediately remove it from all my redhat
> systems. It is not unique at all. As soon as you plug another system
> disk into your system at boot time all hell breaks loose.
That's your fault as a sysadmin ;-)
> At least it
> could have a random number in it or something.
You can use UUIDs today! :)
> If you need to know your bootdisk (why?) why not just get the bootloader
> to tell you?
The only time one cares what the boot disk is, is when _installing_ the
boot loader...
Jeff
Andries Brouwer wrote:
> Such things are infinitely difficult.
> Moreover, great care is needed - one has to define precisely what it
> is this GUID is supposed to be an ID of.
Absolutely agreed.
> (Is it the ZIP drive? Or is it the ZIP disk?
> The 2.4 USB code is broken because it remembers a GUID and thinks that
> identical GUID implies identical disk.)
>
> I have a handful of CF/SM cardreaders.
> Some of them have no form of ID. Others have an ID.
>
> Then one can insert a CF or SM card into the reader.
> Some of these cards have an ID. Some have not.
>
> On the card one usually finds a FAT filesystem.
> There may be a label. Or there may not be.
>
> This describes a 3-level situation.
> I have also 4-level situations, where the reader is filled with
> one of four auxiliary adapters (each with an own ID) and the
> adapter then get a CF/SM/SD/... card.
Using an adapter's ID would be a mistake. You want to use the media's
unique ID, assuming it has one.
> So, yes, we love IDs. And we can always provide them ourselves
> as label or UUID or so in the filesystem.
Not all filesystems have them :)
Further, some sites may prefer block-level GUIDs to fs-level ones.
Sites using raw partitions instead of filesystems, for one.
We must leave this up to the sysadmin -- within the bounds of technology
of course. The sysadmin is out of luck if they purchase a media that
does not support some sort of labelling or UUID.
> But finding an unformatted unlabeled disk is difficult.
You sound like you're agreeing with me ;-)
Jeff
Andries Brouwer wrote:
> On Sun, Sep 14, 2003 at 12:15:27PM +0100, Justin Cormack wrote:
>>If you need to know your bootdisk (why?) why not just get the bootloader
>>to tell you?
> I am not quite sure why anybody would like to know what the bootdisk was.
> The rootdisk, yes, that we need. But the bootdisk?
> Finding it is nontrivial in general. Letting the bootloader tell us
> is also nontrivial.
The bootloader or mkinitrd typically tells the kernel what the root disk
is, so that's not a big deal. The boot disk, OTOH, is tough. Right
now, we just assume the sysadmin knows what's he's doing, when he
installs lilo or grub on a disk. You care about the boot disk when
installing lilo... maybe there are similar situations too which I do not
recall. As Alan said, besides EDD (only on newer boxes) there's really
nothing.
Jeff
On Sul, 2003-09-14 at 18:01, Andries Brouwer wrote:
> I do not understand your complaint.
I sort of do - several vendor installers use fixed labels so
two installs on the same box get very confused. I've seen
novices tie themselves in knots with it before. That isn't
a problem with LABEL=, its an implementation issue with the
vendors install tools, and Red Hat certainly is one of the
parties that made this mistake.
Alan
> Further, some sites may prefer block-level GUIDs to fs-level ones.
> Sites using raw partitions instead of filesystems, for one.
The EFI GUID Partition scheme (aka GPT aka CONFIG_EFI_PARTITION)
stores a GUID in the disk label to define the whole disk, plus another
per-partition GUID and per-partition label. So even if the file
system doesn't have one, if you're using GPT, one *could* use those.
I haven't hacked up mount to search for those though. If there's
enough interest, I'll do so. Recall GPT is currently only used on
ia64, though the code works fine on other arches including x86, and
it's been decided (on l-k at least) that GPT will be the default disk
label format for systems running 2.6.x kernels with disks >2TB, as the
msdos label can't hold it.
> The boot disk, OTOH, is tough. Right now, we just assume the
> sysadmin knows what's he's doing, when he installs lilo or grub on a
> disk. You care about the boot disk when installing lilo... maybe
> there are similar situations too which I do not recall. As Alan
> said, besides EDD (only on newer boxes) there's really nothing.
EDD BIOSs are coming, slowly... 2 work today correctly, several more
are "close but no cigar", it's all the rest that worry me.
There's one more trick that's being used successfully, which I would
like to add to the EDD code. That's "let BIOS help you out before
installing". i.e. you boot into a FreeDOS environment, write a
system-unique disk signature to the boot disk (int13 device 80h)
"BOOT" or something - we've got 4 bytes available in the msdos label
for it, then reboot and let Linux go grab the signature,
store it, and like edd.o does, export it to userspace. Now from
userspace one can see what Linux-named-disk has the signature you're
looking for, and voila, you now solved it w/o needing EDD BIOSs. But
it requires a non-Linux boot step somewhere in the install process.
Thanks,
Matt
--
Matt Domsch
Sr. Software Engineer, Lead Engineer
Dell Linux Solutions http://www.dell.com/linux
Linux on Dell mailing lists @ http://lists.us.dell.com
On Sad, 2003-09-13 at 17:11, Matt Domsch wrote:
> system-unique disk signature to the boot disk (int13 device 80h)
> "BOOT" or something - we've got 4 bytes available in the msdos label
> for it
int 13 is still available during the 16bit boot up phase of the kernel.
It does strike me as playing with fire, but an alternative approach
might work. Read the first 4K off the boot disk, stuff it somewhere
temporary and then in 32bit compare it with the disk starts..
On Sun, Sep 14, 2003 at 05:26:54PM -0500, Alan Cox wrote:
> On Sad, 2003-09-13 at 17:11, Matt Domsch wrote:
> > system-unique disk signature to the boot disk (int13 device 80h)
> > "BOOT" or something - we've got 4 bytes available in the msdos label
> > for it
>
> int 13 is still available during the 16bit boot up phase of the kernel.
> It does strike me as playing with fire, but an alternative approach
> might work. Read the first 4K off the boot disk, stuff it somewhere
> temporary and then in 32bit compare it with the disk starts..
This is essentially what we are proposing, only instead of reading 4K,
read 1 sector and stash the 4-byte disk signature where we can get at
it later, and export it via edd.o for comparison later. This much is
easy, as the empty_zero_page has 512 bytes free for reading the sector
in setup.S, and 4 bytes we can use to stash the signature until
setup.c runs where we can copy it somewhere safe. Then export it via
edd.o through /proc (2.4) or /sys (2.6).
The thing that writes the signature to disk can be anything that can
issue int13 calls. Right now we do it in a FreeDOS app, but a special
loadlin/syslinux/isolinux used for OS installation may be simpler and
not require a FreeDOS environment be run ever.
-Matt
--
Matt Domsch
Sr. Software Engineer, Lead Engineer
Dell Linux Solutions http://www.dell.com/linux
Linux on Dell mailing lists @ http://lists.us.dell.com
Matt:
This would require the generic mapping of disc labels away from the
current hdX/sdX to hdN where 0 =< N < 5. This issue will be mapping EDDS
which you are working on, and I tip my hat for what value it has left.
I will chat offline more in details to see where you are going and if I
can offer help from the T13 side of life.
Cheers,
Andre Hedrick
LAD Storage Consulting Group
On Sat, 13 Sep 2003, Matt Domsch wrote:
> > Further, some sites may prefer block-level GUIDs to fs-level ones.
> > Sites using raw partitions instead of filesystems, for one.
>
> The EFI GUID Partition scheme (aka GPT aka CONFIG_EFI_PARTITION)
> stores a GUID in the disk label to define the whole disk, plus another
> per-partition GUID and per-partition label. So even if the file
> system doesn't have one, if you're using GPT, one *could* use those.
> I haven't hacked up mount to search for those though. If there's
> enough interest, I'll do so. Recall GPT is currently only used on
> ia64, though the code works fine on other arches including x86, and
> it's been decided (on l-k at least) that GPT will be the default disk
> label format for systems running 2.6.x kernels with disks >2TB, as the
> msdos label can't hold it.
>
> > The boot disk, OTOH, is tough. Right now, we just assume the
> > sysadmin knows what's he's doing, when he installs lilo or grub on a
> > disk. You care about the boot disk when installing lilo... maybe
> > there are similar situations too which I do not recall. As Alan
> > said, besides EDD (only on newer boxes) there's really nothing.
>
> EDD BIOSs are coming, slowly... 2 work today correctly, several more
> are "close but no cigar", it's all the rest that worry me.
>
> There's one more trick that's being used successfully, which I would
> like to add to the EDD code. That's "let BIOS help you out before
> installing". i.e. you boot into a FreeDOS environment, write a
> system-unique disk signature to the boot disk (int13 device 80h)
> "BOOT" or something - we've got 4 bytes available in the msdos label
> for it, then reboot and let Linux go grab the signature,
> store it, and like edd.o does, export it to userspace. Now from
> userspace one can see what Linux-named-disk has the signature you're
> looking for, and voila, you now solved it w/o needing EDD BIOSs. But
> it requires a non-Linux boot step somewhere in the install process.
>
> Thanks,
> Matt
>
> --
> Matt Domsch
> Sr. Software Engineer, Lead Engineer
> Dell Linux Solutions http://www.dell.com/linux
> Linux on Dell mailing lists @ http://lists.us.dell.com
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
On Sat, Sep 13 2003, Jeff Garzik wrote:
> Oh, and I'm pondering the best way to deliver out-of-bang ATA taskfiles
> and SCSI cdbs to a device. (for the uninitiated, this is lower level
> than block devices / cdrom devices / etc.)
>
> ... AF_BLOCK is not out of the question ;-)
Eh... I wont comment on that. I think we are way into Garzik lala land
there :)
I'd prefer just keeping sg_io_hdr, but dumping sg. A fully fledged bsg
(block sg) implementation. That way programs continue to work like
before on ATAPI/SCSI, for ATA we can use it as a task file transport.
--
Jens Axboe
On Sun, 14 Sep 2003, Alan Cox wrote:
> On Sul, 2003-09-14 at 18:01, Andries Brouwer wrote:
> > I do not understand your complaint.
>
> I sort of do - several vendor installers use fixed labels so
> two installs on the same box get very confused. I've seen
> novices tie themselves in knots with it before. That isn't
> a problem with LABEL=, its an implementation issue with the
> vendors install tools, and Red Hat certainly is one of the
> parties that made this mistake.
LABEL= is the wrong solution to the right problem, IMHO. It only seems to
make sense if you are a distributor trying to make a one size mostly fits
all. If you tinker with your system it only seems to get in the way.
It seems to me that if you are in the position of tinkering, and
installing an OS you ought to have an understanding of root and boot
disks, and what is in your system. If you don't understand things well
enough to specify the proper boot disk and root disk you shouldn't be
tinkering and it won't matter how each is specified.
On Maw, 2003-09-16 at 03:38, Thomas Molina wrote:
> It seems to me that if you are in the position of tinkering, and
> installing an OS you ought to have an understanding of root and boot
> disks, and what is in your system. If you don't understand things well
> enough to specify the proper boot disk and root disk you shouldn't be
> tinkering and it won't matter how each is specified.
Your root disk can change for all sorts of non Linux reasons ranging
from windows config changes to hotplug devices. For example if your root
is /dev/sdc and /dev/sdb fails you'll want LABEL=.
On Mon, Sep 15, 2003 at 09:34:45AM +0200, Jens Axboe wrote:
> On Sat, Sep 13 2003, Jeff Garzik wrote:
> > Oh, and I'm pondering the best way to deliver out-of-bang ATA taskfiles
> > and SCSI cdbs to a device. (for the uninitiated, this is lower level
> > than block devices / cdrom devices / etc.)
> >
> > ... AF_BLOCK is not out of the question ;-)
>
> Eh... I wont comment on that. I think we are way into Garzik lala land
> there :)
>
> I'd prefer just keeping sg_io_hdr, but dumping sg. A fully fledged bsg
> (block sg) implementation. That way programs continue to work like
> before on ATAPI/SCSI, for ATA we can use it as a task file transport.
I don't propose dumping the ugly "submit cdb/taskfile" ioctls, but we do
need to deprecate them. The ioctls are awful for throughput, async
queueing, and the like. And of course in general, ioctls are evil :)
And we should deprecate them with a solution that aligns what with Linus
described in Dec 2001 on lkml: a chrdev where userland write(2)s cdbs
and taskfiles, and read(2)s the results. This is where my thinking
picked up: if we are creating a chrdev to send "packets" and receive
responses to those packets............ <insert conclusion here>
Jeff
On Tue, Sep 16 2003, Jeff Garzik wrote:
> On Mon, Sep 15, 2003 at 09:34:45AM +0200, Jens Axboe wrote:
> > On Sat, Sep 13 2003, Jeff Garzik wrote:
> > > Oh, and I'm pondering the best way to deliver out-of-bang ATA taskfiles
> > > and SCSI cdbs to a device. (for the uninitiated, this is lower level
> > > than block devices / cdrom devices / etc.)
> > >
> > > ... AF_BLOCK is not out of the question ;-)
> >
> > Eh... I wont comment on that. I think we are way into Garzik lala land
> > there :)
> >
> > I'd prefer just keeping sg_io_hdr, but dumping sg. A fully fledged bsg
> > (block sg) implementation. That way programs continue to work like
> > before on ATAPI/SCSI, for ATA we can use it as a task file transport.
>
> I don't propose dumping the ugly "submit cdb/taskfile" ioctls, but we do
> need to deprecate them. The ioctls are awful for throughput, async
> queueing, and the like. And of course in general, ioctls are evil :)
>
> And we should deprecate them with a solution that aligns what with Linus
> described in Dec 2001 on lkml: a chrdev where userland write(2)s cdbs
> and taskfiles, and read(2)s the results. This is where my thinking
> picked up: if we are creating a chrdev to send "packets" and receive
> responses to those packets............ <insert conclusion here>
== bsg, block sg. Did you read what I wrote? :). I started implementing
this and have something that barely works. You just bind a block device
to a /dev/sg* char device and use read/write on that. Aka sg.
I don't want ioctls command submission interfaces more than you do.
--
Jens Axboe
Jens Axboe wrote:
> On Tue, Sep 16 2003, Jeff Garzik wrote:
>>And we should deprecate them with a solution that aligns what with Linus
>>described in Dec 2001 on lkml: a chrdev where userland write(2)s cdbs
>>and taskfiles, and read(2)s the results. This is where my thinking
>>picked up: if we are creating a chrdev to send "packets" and receive
>>responses to those packets............ <insert conclusion here>
>
>
> == bsg, block sg. Did you read what I wrote? :). I started implementing
> this and have something that barely works. You just bind a block device
> to a /dev/sg* char device and use read/write on that. Aka sg.
sg needs some modifications -- for example it errors out instead of
sleeps on queue full -- but sounds good to me.
> I don't want ioctls command submission interfaces more than you do.
Groovy.
Jeff
Alan Cox wrote:
> On Sad, 2003-09-20 at 19:28, Jeff Garzik wrote:
>
>>sg needs some modifications -- for example it errors out instead of
>>sleeps on queue full -- but sounds good to me.
>
>
> Is that an error and change in behaviour ?
No and yes. :)
Current sg breaks the Unix model of write(2)... you shouldn't error out
if the queue will "probably" become available again.
Jeff
On Sad, 2003-09-20 at 19:28, Jeff Garzik wrote:
> sg needs some modifications -- for example it errors out instead of
> sleeps on queue full -- but sounds good to me.
Is that an error and change in behaviour ?
On Sad, 2003-09-20 at 23:22, Jeff Garzik wrote:
> > Is that an error and change in behaviour ?
>
>
> No and yes. :)
>
> Current sg breaks the Unix model of write(2)... you shouldn't error out
> if the queue will "probably" become available again.
Thats what I thought - because apps want to know if the queue is full
when doing raw scsi work some of the time. Would the change break any
known apps - if not it seems fine (providing O_NDELAY is supported)
On Sat, Sep 20 2003, Jeff Garzik wrote:
> Jens Axboe wrote:
> >On Tue, Sep 16 2003, Jeff Garzik wrote:
>
> >>And we should deprecate them with a solution that aligns what with Linus
> >>described in Dec 2001 on lkml: a chrdev where userland write(2)s cdbs
> >>and taskfiles, and read(2)s the results. This is where my thinking
> >>picked up: if we are creating a chrdev to send "packets" and receive
> >>responses to those packets............ <insert conclusion here>
> >
> >
> >== bsg, block sg. Did you read what I wrote? :). I started implementing
> >this and have something that barely works. You just bind a block device
> >to a /dev/sg* char device and use read/write on that. Aka sg.
>
> sg needs some modifications -- for example it errors out instead of
> sleeps on queue full -- but sounds good to me.
Definitely. bsg will be a new implementation from scratch, also dumping
a lot of really (imo) useless "features" that clutter up the code. And
yes, of course it should honor the typical write(2) model :)
--
Jens Axboe
On Sun, Sep 14, 2003 at 05:26:54PM -0500, Alan Cox wrote:
> On Sad, 2003-09-13 at 17:11, Matt Domsch wrote:
> > system-unique disk signature to the boot disk (int13 device 80h)
> > "BOOT" or something - we've got 4 bytes available in the msdos label
> > for it
>
> int 13 is still available during the 16bit boot up phase of the kernel.
> It does strike me as playing with fire, but an alternative approach
> might work. Read the first 4K off the boot disk, stuff it somewhere
> temporary and then in 32bit compare it with the disk starts..
This is what I had in mind.
linux-2.4.23-pre4
+ http://domsch.com/linux/edd30/linux/linux-2.4.23-pre4-edd-20030914.patch.gz
+ patch below
Documentation/i386/zero-page.txt | 4 +++-
arch/i386/boot/setup.S | 21 +++++++++++++++++++++
arch/i386/kernel/edd.c | 27 +++++++++++++++++++++++++--
arch/i386/kernel/i386_ksyms.c | 1 +
arch/i386/kernel/setup.c | 3 +++
include/asm-i386/edd.h | 7 ++++++-
6 files changed, 59 insertions(+), 4 deletions(-)
This puts the 4-byte disk signature into
/proc/bios/edd/int13_dev80/mbr_signature
Thanks,
Matt
--
Matt Domsch
Sr. Software Engineer, Lead Engineer
Dell Linux Solutions http://www.dell.com/linux
Linux on Dell mailing lists @ http://lists.us.dell.com
diff -Nru a/Documentation/i386/zero-page.txt b/Documentation/i386/zero-page.txt
--- a/Documentation/i386/zero-page.txt Mon Sep 15 17:00:58 2003
+++ b/Documentation/i386/zero-page.txt Mon Sep 15 17:00:58 2003
@@ -66,8 +66,10 @@
0x21c unsigned long INITRD_SIZE, size in bytes of ramdisk image
0x220 4 bytes (setup.S)
0x224 unsigned short setup.S heap end pointer
+0x228 4 bytes DISK80_SIG_BUFFER (setup.S)
0x2d0 - 0x600 E820MAP
-0x600 - 0x7D4 EDDBUF (setup.S)
+0x600 - 0x800 EDDBUF (setup.S) for disk signature read sector
+0x600 - 0x7d4 EDDBUF (setup.S)
0x800 string, 2K max COMMAND_LINE, the kernel commandline as
copied using CL_OFFSET.
diff -Nru a/arch/i386/boot/setup.S b/arch/i386/boot/setup.S
--- a/arch/i386/boot/setup.S Mon Sep 15 17:00:58 2003
+++ b/arch/i386/boot/setup.S Mon Sep 15 17:00:58 2003
@@ -49,6 +49,8 @@
* by Matt Domsch <[email protected]> October 2002
* conformant to T13 Committee http://www.t13.org
* projects 1572D, 1484D, 1386D, 1226DT
+ * disk signature read by Matt Domsch <[email protected]>
+ * and Andrew Wilks <[email protected]> September 2003
*/
#include <linux/config.h>
@@ -549,6 +551,25 @@
#endif
#if defined(CONFIG_EDD) || defined(CONFIG_EDD_MODULE)
+# Read the first sector of device 80h and store the 4-byte signature
+ movl $0xFFFFFFFF, %eax
+ movl %eax, (DISK80_SIG_BUFFER) # assume failure
+ movb $READ_SECTORS, %ah
+ movb $1, %al # read 1 sector
+ movb $0x80, %dl # from device 80
+ movb $0, %dh # at head 0
+ movw $1, %cx # cylinder 0, sector 0
+ pushw %es
+ pushw %ds
+ popw %es
+ movw $EDDBUF, %bx
+ int $0x13
+ jc disk_sig_done
+ movl (EDDBUF+MBR_SIG_OFFSET), %eax
+ movl %eax, (DISK80_SIG_BUFFER) # store success
+disk_sig_done:
+ popw %es
+
# Do the BIOS Enhanced Disk Drive calls
# This consists of two calls:
# int 13h ah=41h "Check Extensions Present"
diff -Nru a/arch/i386/kernel/edd.c b/arch/i386/kernel/edd.c
--- a/arch/i386/kernel/edd.c Mon Sep 15 17:00:58 2003
+++ b/arch/i386/kernel/edd.c Mon Sep 15 17:00:58 2003
@@ -1,7 +1,8 @@
/*
* linux/arch/i386/kernel/edd.c
- * Copyright (C) 2002 Dell Computer Corporation
+ * Copyright (C) 2002, 2003 Dell, Inc.
* by Matt Domsch <[email protected]>
+ * disk80 signature by Matt Domsch, Andrew Wilks, and Sandeep K. Shandilya
*
* BIOS Enhanced Disk Drive Services (EDD)
* conformant to T13 Committee http://www.t13.org
@@ -27,7 +28,6 @@
/*
* TODO:
* - move edd.[ch] to better locations if/when one is decided
- * - keep current with 2.5 EDD code changes
*/
#include <linux/module.h>
@@ -333,6 +333,18 @@
}
static int
+edd_show_disk80_sig(char *page, char **start, off_t off, int count, int *eof, void *data)
+{
+ char *p = page;
+ if ( !page || off) {
+ return proc_calc_metrics(page, start, off, count, eof, 0);
+ }
+
+ p += snprintf(p, left, "0x%08x\n", edd_disk80_sig);
+ return proc_calc_metrics(page, start, off, count, eof, (p - page));
+}
+
+static int
edd_show_extensions(char *page, char **start, off_t off, int count, int *eof, void *data)
{
struct edd_info *info = data;
@@ -491,6 +503,15 @@
return 1;
}
+static int
+edd_has_disk80_sig(struct edd_device *edev)
+{
+ struct edd_info *info = edd_dev_get_info(edev);
+ if (!edev || !info)
+ return 0;
+ return info->device == 0x80;
+}
+
static EDD_DEVICE_ATTR(raw_data, edd_show_raw_data, NULL);
static EDD_DEVICE_ATTR(version, edd_show_version, NULL);
static EDD_DEVICE_ATTR(extensions, edd_show_extensions, NULL);
@@ -505,6 +526,7 @@
edd_has_default_sectors_per_track);
static EDD_DEVICE_ATTR(interface, edd_show_interface,edd_has_edd30);
static EDD_DEVICE_ATTR(host_bus, edd_show_host_bus, edd_has_edd30);
+static EDD_DEVICE_ATTR(mbr_signature, edd_show_disk80_sig, edd_has_disk80_sig);
static struct edd_attribute *def_attrs[] = {
&edd_attr_raw_data,
@@ -517,6 +539,7 @@
&edd_attr_default_sectors_per_track,
&edd_attr_interface,
&edd_attr_host_bus,
+ &edd_attr_mbr_signature,
NULL,
};
diff -Nru a/arch/i386/kernel/i386_ksyms.c b/arch/i386/kernel/i386_ksyms.c
--- a/arch/i386/kernel/i386_ksyms.c Mon Sep 15 17:00:58 2003
+++ b/arch/i386/kernel/i386_ksyms.c Mon Sep 15 17:00:58 2003
@@ -185,4 +185,5 @@
#ifdef CONFIG_EDD_MODULE
EXPORT_SYMBOL(edd);
EXPORT_SYMBOL(eddnr);
+EXPORT_SYMBOL(edd_disk80_sig);
#endif
diff -Nru a/arch/i386/kernel/setup.c b/arch/i386/kernel/setup.c
--- a/arch/i386/kernel/setup.c Mon Sep 15 17:00:58 2003
+++ b/arch/i386/kernel/setup.c Mon Sep 15 17:00:58 2003
@@ -212,6 +212,7 @@
#define KERNEL_START (*(unsigned long *) (PARAM+0x214))
#define INITRD_START (*(unsigned long *) (PARAM+0x218))
#define INITRD_SIZE (*(unsigned long *) (PARAM+0x21c))
+#define DISK80_SIGNATURE (*(unsigned int*) (PARAM+DISK80_SIG_BUFFER))
#define EDD_NR (*(unsigned char *) (PARAM+EDDNR))
#define EDD_BUF ((struct edd_info *) (PARAM+EDDBUF))
#define COMMAND_LINE ((char *) (PARAM+2048))
@@ -721,6 +722,7 @@
#if defined(CONFIG_EDD) || defined(CONFIG_EDD_MODULE)
unsigned char eddnr;
struct edd_info edd[EDDMAXNR];
+unsigned int edd_disk80_sig;
/**
* copy_edd() - Copy the BIOS EDD information
* from empty_zero_page into a safe place.
@@ -730,6 +732,7 @@
{
eddnr = EDD_NR;
memcpy(edd, EDD_BUF, sizeof(edd));
+ edd_disk80_sig = DISK80_SIGNATURE;
}
#else
static inline void copy_edd(void) {}
diff -Nru a/include/asm-i386/edd.h b/include/asm-i386/edd.h
--- a/include/asm-i386/edd.h Mon Sep 15 17:00:58 2003
+++ b/include/asm-i386/edd.h Mon Sep 15 17:00:58 2003
@@ -1,6 +1,6 @@
/*
* linux/include/asm-i386/edd.h
- * Copyright (C) 2002 Dell Computer Corporation
+ * Copyright (C) 2002, 2003 Dell, Inc.
* by Matt Domsch <[email protected]>
*
* structures and definitions for the int 13h, ax={41,48}h
@@ -41,6 +41,10 @@
#define EDDMAGIC1 0x55AA
#define EDDMAGIC2 0xAA55
+#define READ_SECTORS 0x02
+#define MBR_SIG_OFFSET 0x1B8
+#define DISK80_SIG_BUFFER 0x228
+
#ifndef __ASSEMBLY__
#define EDD_EXT_FIXED_DISK_ACCESS (1 << 0)
@@ -167,6 +171,7 @@
extern struct edd_info edd[EDDMAXNR];
extern unsigned char eddnr;
+extern unsigned int edd_disk80_sig;
#endif /*!__ASSEMBLY__ */
#endif /* _ASM_I386_EDD_H */