3 Questions

3 Questions

[Joachim Martillo]

1) I have built a multifunction driver to support the Aurora
Technologies, Inc. serial adapter cards and expansion units that use
Siemens/Infineon SAB 82532 and SAB 82538 (ESCC2 and ESCC8) enhanced
serial communications controllers.  This driver supports asynchronous
TTYs, synchronous TTYs, an Ethernet-like synchronous serial Network
driver, and a packet-oriented character device to facilitate the
portation to Linux of synchronous protocol applications that have been
implemented with putmsg and getmsg on proprietary Unix systems.  (A
patch for those interested in trying the driver will be put up on one
of my web pages shortly.)  I took the SPARC Linux SAB 82532 serial
asynchronous TTY driver as a starting point and kept the
block_til_ready logic that arbitrates access between the cua and ttyS
devices because it seemed helpful in arbitrating access to a physical
port among the asynchronous TTY, asynchronous call out, synchronous
TTY, Network and character device functionalities.  From reviewing the
archive, I noticed that the cua devices have been deprecated, and that
now apparently callout and asynchronous terminal connectivity are
supposed to be managed through a single port.  I am not sure how
asynchronous dialout for synchronous TTYs, synchronous Network devices
and the synchronous character device can be managed without a separate
asynchronous callout device to communicate with the modem before the
synchronous connection is set up.  I suppose I could modify the
asynchronous TTY device so that it could be bimodal and switch back
and forth between synchronous and asynchronous mode, but a similar
procedure would be hard for the synchronous character device and very
hard for the synchronous network device.  How is dialout supposed to
be handled for asynchronous dialup modems that can set up synchronous
point-to-point connections on demand?

2) Are the other PCI or (E)ISA serial adapter cards that use the
SAB82532 and SAB82538 enhanced serial communications controller?
I could add support for them into this driver.

3) Aurora wants to track the driver in its source control system, but
they have ISO 900X procedures that require maintaining the build
environment under CVS.  The build environment is basically the kernel
against which it is developed.  But new developer kernels are released
fairly regularly (unlike new versions of Solaris or True64).  Do
maintainers of such driver software commonly maintain development
environments across a complete range (e.g., all 2.4.* kernels)?  Is
there a FAQ with recommendations to help a hardware vendor deal with
the nitty gritty details of making sure its driver software works
properly across such a range of rapidly changing development
environments?


Joachim Martillo
Telford Tools, Inc.
martillo@telfordtools.com

Re: 3 Questions

[Alan Cox]

> 3) Aurora wants to track the driver in its source control system, but
> they have ISO 900X procedures that require maintaining the build
> environment under CVS.  The build environment is basically the kernel
> against which it is developed.  But new developer kernels are released
> fairly regularly (unlike new versions of Solaris or True64).  Do
> maintainers of such driver software commonly maintain development
> environments across a complete range (e.g., all 2.4.* kernels)?  Is
> there a FAQ with recommendations to help a hardware vendor deal with
> the nitty gritty details of making sure its driver software works
> properly across such a range of rapidly changing development
> environments?

Generally driver vendors only certify/support against "standard" vendor
released kernels. So instead of Linux they support "SuSE 7.3" "Red Hat 7.2"
etc..

Most also make a clear distinction between what is submitted to the GPL and
hacked about under the GPL, and what they will provide any guarantee on. 

Think of it like a car.
	The engine is only supported for the car it was designed for
	You can rebore the engine but you wont get support
	You can stick the engine in a different car but you wont get support

Alan

Re: 3 Questions

[Allan Sandfeld]

On Wednesday 28 November 2001 21:12, Alan Cox wrote:
> > 3) Aurora wants to track the driver in its source control system, but
> > they have ISO 900X procedures that require maintaining the build
> > environment under CVS.  The build environment is basically the kernel
> > against which it is developed.  But new developer kernels are released
> > fairly regularly (unlike new versions of Solaris or True64).  Do
> > maintainers of such driver software commonly maintain development
> > environments across a complete range (e.g., all 2.4.* kernels)?  Is
> > there a FAQ with recommendations to help a hardware vendor deal with
> > the nitty gritty details of making sure its driver software works
> > properly across such a range of rapidly changing development
> > environments?
>
> Generally driver vendors only certify/support against "standard" vendor
> released kernels. So instead of Linux they support "SuSE 7.3" "Red Hat 7.2"
> etc..
>
> Most also make a clear distinction between what is submitted to the GPL and
> hacked about under the GPL, and what they will provide any guarantee on.
>
> Think of it like a car.
> 	The engine is only supported for the car it was designed for
> 	You can rebore the engine but you wont get support
> 	You can stick the engine in a different car but you wont get support
>

Unless they release it GPL, then it might be included in the kernel right? 
And "the nitty gritty details of making sure its driver software works
properly across such a range of rapidly changing development
environments" taken care of by the users of the driver.  They can even track 
it by CVS, by requesting all patches against the driver to be submitted to 
them.

They asked for official recommendations, shouldnt the primary recommandation 
not be to open source it, even if some vendors wont?

Regards

Re: 3 Questions

[Alan Cox]

> Unless they release it GPL, then it might be included in the kernel right? 
> And "the nitty gritty details of making sure its driver software works
> properly across such a range of rapidly changing development
> environments" taken care of by the users of the driver.  They can even track 
> it by CVS, by requesting all patches against the driver to be submitted to 
> them.

Seperate "works" from "supported by". Putting a driver in the kernel makes a
lot of sense, but you'd still probably have an officially supported version.

> They asked for official recommendations, shouldnt the primary recommandation 
> not be to open source it, even if some vendors wont?

They have to open source it anyway, since it is based on the sbus aurora
driver as they said, so its already GPL code.

There is a difference between releasing GPL code and supporting it. Standard
Red Hat support contracts for example stop at the point you go compiling
your own kernel.

3 questions...

[Shaw, Marco]

1. When using fdisk, is it really required (or a "good idea") to create the partitions as type "fd"?  I've typically just created a regular Linux partition, and would let mkraid to it's thing.  (As a result, it seems strange that I ran into #2 below since I didn't do this step of changing the type.)

2. I can't seem to find a document describing how software RAID really works technically.  (Yes, I could read the source, but I'm not the most proficient C person, nor do I want to work all weekend looking at the source either.)  I had a problem the other day, where I had a md0 device that the system was not able to mount (logical disks mounted from a SAN).  Because the system could not mount the disks, it would fail to boot at the section where the system would attempt to auto-detect md0 and would drop me to single-user mode type prompt.

Taking the directory out of fstab, and tried to find something in /etc/rc.d/init.d that was trying to do stuff with the md devices at boot but couldn't find anything.  Ended up being a problem with an old modular driver, and had to create a new initrd with an updated driver, but I was stuck for a second (well more than a second really).

3. Is "persistent-superblock" supported with Linear and RAID0?  I think chunk-size is only supported in RAID0 and higher, but Linear will just skip the configuration with an informational warning at boot.

Marco

PS Basing some of my assumptions/statements above from the Software-RAID HOWTO v. 0.90.7.

Re: 3 questions...

[Michael Tokarev]

Shaw, Marco wrote:
> 1. When using fdisk, is it really required (or a "good idea") to
 > create the partitions as type "fd"?  I've typically just created
 > a regular Linux partition, and would let mkraid to it's thing.

No.  Raid code will happily use any partition type you'll specify.
Partition type "fd" stands for "raid AUTODETECT" - that is, at
bootup, kernel looks at your partitions of this type (if any)
to automatically bring up an array that may be required for your
root filesystem.  But instead of guessing, it is better IMHO to
just tell kernel which devices to use for your root filesystem
(if your root is on raid device), by using something like
  append="md=2,/dev/hda1,/dev/hdb1"
in your lilo.conf or similar (to mean bring up /dev/md2 consisting
of /dev/hda1 and /dev/hdb1 - you should got an idea).
Non-root arrays may be set up just easily from your real root
filesystem.  In either way, do not bother using "fd" partition
type for non-automatically-started-root-fs device.  For me,
I don't use autodetect at all since it will be a PITA if I'll
need to insert drives from one machine to another - on another
machine I may get just unpredictable results after kernel will
try to bring up autodetected raid arrays from both own disks
and disk from foreign machine (btw, it will be nice to DISABLE
raid autodetection completely for this very reason, as it was
possible on 2.2 kernels).

 > (As a result, it seems strange that I ran into #2 below since I
 > didn't do this step of changing the type.)
> 
> 2. I can't seem to find a document describing how software RAID
 > really works technically.  (Yes, I could read the source, but I'm
 > not the most proficient C person, nor do I want to work all weekend
 > looking at the source either.)  I had a problem the other day,
 > where I had a md0 device that the system was not able to mount
 > (logical disks mounted from a SAN).  Because the system could not
 > mount the disks, it would fail to boot at the section where the
 > system would attempt to auto-detect md0 and would drop me to
 > single-user mode type prompt.

An array should be started before it can be mounted (that should
be obvious, right?).  You may got single-user prompt *only* if
your root filesystem was mounted successefully (or else you'd
got kernel panic instead).  So, an answer is in your startup
scripts -- there should be a script that brings raid arrays
up before mounting filesystems, and there should be some file
where an information about how to assemble arrays is stored
(maybe /etc/raidtab or /etc/mdadm.conf).  But this highly
depends on distribution you use, and I can't help you here.

> Taking the directory out of fstab, and tried to find something
 > in /etc/rc.d/init.d that was trying to do stuff with the md
 > devices at boot but couldn't find anything.  Ended up being
 > a problem with an old modular driver, and had to create a new
 > initrd with an updated driver, but I was stuck for a second
 > (well more than a second really).
> 
> 3. Is "persistent-superblock" supported with Linear and RAID0?
 > I think chunk-size is only supported in RAID0 and higher, but
 > Linear will just skip the configuration with an informational
 > warning at boot.

I think persistent-superblocks are supported with all raid levels,
but I may be wrong.  At least, raid0 has this feature for sure.

/mjt

Re: 3 questions...

[Florent Rougon]

Hi,

Michael Tokarev <mjt@tls.msk.ru> wrote:

> No.  Raid code will happily use any partition type you'll specify.
> Partition type "fd" stands for "raid AUTODETECT" - that is, at

[...]

> root filesystem.  But instead of guessing, it is better IMHO to
> just tell kernel which devices to use for your root filesystem
> (if your root is on raid device), by using something like
>   append="md=2,/dev/hda1,/dev/hdb1"

I have some partitions with the fd type in raid arrays but would like to
switch to the manual method you just described. These partitions hold
data I care about. Is it safe to change the partition type:
   - while the array is not active?
   - while the array is active?

Thanks.

-- 
Florent

Re: 3 questions...

[Michael Tokarev]

Florent Rougon wrote:
[]
> I have some partitions with the fd type in raid arrays but would like to
> switch to the manual method you just described. These partitions hold
> data I care about. Is it safe to change the partition type:
>    - while the array is not active?
>    - while the array is active?

Hmm, it's always a good idea to have a backup handy, just in
case, right? ;)

Kernel code does not care about partition table _at all_ while
disk is in use - kernel reads partition table when disk usage
goes from 0 to 1, and keeps that table in memory after that, so
you may do with your partitions *anything* you like (incl. erasing
the whole table) while it's in use (but do not forget to restore
things before next reboot ;).  Concerning changing partition type,
well - having an accurate tool for this, it shuld be safe (an
operation is very simple, just changing one byte in disk's partition
table (an area that isn't used for anything else)).  So, answer
to both your question is yes, but see my first statement (in
fact, it is NOT completely safe to do ANYTHING at all with your
data - kernel may screw up and write random garbage to your
disks just at any time, even if you told it to mount a filesystem
read-only -- and disk may crash at random... ;).  Oh well... ;)
(don't panic, however - that's quite normal!.. ;)

/mj

Re: 3 questions...

[Florent Rougon]

Michael Tokarev <mjt@tls.msk.ru> wrote:

> Hmm, it's always a good idea to have a backup handy, just in
> case, right? ;)

Oh, yes.

> Kernel code does not care about partition table _at all_ while
> disk is in use - kernel reads partition table when disk usage
> goes from 0 to 1, and keeps that table in memory after that, so

[...]

> table (an area that isn't used for anything else)).  So, answer
> to both your question is yes, but see my first statement (in

[...]

Thank you very much for this detailed answer.

-- 
Florent

RE: 3 questions...

[Shaw, Marco]

> > tell kernel which devices to use for your root filesystem (if your 
> > root is on raid device), by using something like
> >   append="md=2,/dev/hda1,/dev/hdb1"
> 
> I have some partitions with the fd type in raid arrays but 
> would like to switch to the manual method you just described. 
> These partitions hold data I care about. Is it safe to change 
> the partition type:
>    - while the array is not active?
>    - while the array is active?

I would recommend to umount the array and stop it if you can.  The fd or default 83 (IIRC), is just a label on the disk, and won't destroy data.  I've more experience with labels on Solaris, and have done those "on-the-fly" with no affects though.

Remember (with RedHat Advanced Server anyway), you'd have to actually disable autodetection.  I'm still working on how it works because I'm still unclear whether this is a kernel feature, or just a result of init scripts.  An older RedHat reference:
http://www.redhat.com/support/resources/tips/raid/RAID-4.html

Marco

Re: 3 questions...

[Michael Tokarev]

Shaw, Marco wrote:
[]
> Remember (with RedHat Advanced Server anyway), you'd have to actually disable autodetection.  I'm still working on how it works because I'm still unclear whether this is a kernel feature, or just a result of init scripts.  An older RedHat reference:
> http://www.redhat.com/support/resources/tips/raid/RAID-4.html

Autodetection works in kernel, before kernel tries to
mount root filesystem.  At this time, kernel looks at
all partitions of type "raid autodetect" to see if this
is a part of an array, and brings up all it can find
(In fact, this seems to be not true sisnce at least on
2.2 here, only root mddev is started while another two
also marked as "autodetect").  The rest is done in
initscripts, after root filesystem gets mounted (kernel
has no clue about initscripts at all).

/mjt