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
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.
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
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
- 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:
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
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
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.
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
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
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
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
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
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
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
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
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
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
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
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
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
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 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
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
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
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
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.
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
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
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
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
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
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
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
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.
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
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
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
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
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
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
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.
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:
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
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
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
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
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
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,
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
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
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
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
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
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
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
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
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
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
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
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 -=-
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
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
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
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
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
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. :-)
67 matches
Mail list logo
