Linux-Development-Sys Digest #252, Volume #8 Thu, 2 Nov 00 10:13:11 EST
Contents:
2.4.0-test9 compile error ([EMAIL PROTECTED])
Re: Linux API (Josef Moellers)
Re: Disk Replication (bootable) (Josef Moellers)
How to control parallel port from user level? ("Christoph")
verify_area(..) error ([EMAIL PROTECTED])
Re: Disk Replication (bootable) (Kasper Dupont)
Re: How to control parallel port from user level? (Kasper Dupont)
RAID5 under 2.4.0-test9 ("U. Siegel")
Stacking Kernel Drivers ("Francois Groenewald")
Re: RFI: Linux implementation of tnf tracing system (Andi Kleen)
Re: Disk Replication (bootable) (Bernd Strieder)
Re: Disk Replication (bootable) (Tom J)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED]
Subject: 2.4.0-test9 compile error
Date: Thu, 02 Nov 2000 06:38:42 -0000
gcc -D__KERNEL__ -I/home/root/kernel/linux/include -Wall -Wstrict-prototypes -O2
-fomit-frame-pointer -pipe -march=i686 -fno-strict-aliasing -c -o i810_rng.o
i810_rng.c
i810_rng.c: In function `rng_enable':
i810_rng.c:384: warning: dereferencing `void *' pointer
i810_rng.c:384: request for member `uc' in something not a structure or union
i810_rng.c:386: warning: dereferencing `void *' pointer
i810_rng.c:386: request for member `uc' in something not a structure or union
make[3]: *** [i810_rng.o] Error 1
make[3]: Leaving directory `/home/root/kernel/linux/drivers/char'
make[2]: *** [first_rule] Error 2
make[2]: Leaving directory `/home/root/kernel/linux/drivers/char'
make[1]: *** [_subdir_char] Error 2
make[1]: Leaving directory `/home/root/kernel/linux/drivers'
make: *** [_dir_drivers] Error 2
The affected code looks like (errors on the lines with GET_USE_COUNT):
#ifndef __alpha__
if (GET_USE_COUNT (THIS_MODULE) > 0)
MOD_DEC_USE_COUNT;
if (GET_USE_COUNT (THIS_MODULE) == 0)
rng_hw_enabled = 0;
#endif
I'm just going to reconfigure this out and try again for now.
--
| Phil Howard - KA9WGN | My current websites: linuxhomepage.com, ham.org
| phil (at) ipal.net +----------------------------------------------------
| Dallas - Texas - USA | [EMAIL PROTECTED]
------------------------------
From: Josef Moellers <[EMAIL PROTECTED]>
Subject: Re: Linux API
Date: Thu, 02 Nov 2000 09:04:45 +0100
Nick Maclaren wrote:
[ "The source code is the API" omitted ]
> However, reading the source doesn't help, in general. All it
> usually tells you is what the current version does, and not which
> aspects will remain invariant over future releases. It CAN tell
> you whether a misbehaviour is deliberate or accidental (i.e. a
> 'feature' or a bug), but that is about all.
Very well said. IMHO source code is just "an implementation" of an API,
and a specific source code may very well be a faulty implementation. It
is stated very often that the manual pages are the API and if you used a
feature which was not described in the manual pages, then you were
treading on very thin ice. Also, some major software company Whose Name
Must Not Be Told is always frowned upon because they have these "hidden"
and "undocumented" features.
The source code may come in handy if you want to check upon a feature
whose description you don't really understand or when the
implementation's behaviour differs from your expectation. The answer
"UTSL" may only be given to questions about "how" not "what" a function
does.
When I started working after school, the system I worked on (a small
office system) had no distinction between kernel and user space and all
over our company people had access to the necessary programming tools
(assembler and BASIC B-{) to write software. There were people (e.g. in
marketing B-{) who looked into the source code, found a nifty feature
(sometimes just a constant which they picked up, because the machine
architecture, a DG Nove clone, didn't provide for arbitrary constants)
and started using it. When you wanted to modify the source, you had to
go to great lengths to keep those programs running which used this
"feature".
-- =
Josef M=F6llers (Pinguinpfleger bei FSC)
If failure had no penalty success would not be a prize (T. Pratchett)
------------------------------
From: Josef Moellers <[EMAIL PROTECTED]>
Subject: Re: Disk Replication (bootable)
Date: Thu, 02 Nov 2000 09:11:54 +0100
Tom J wrote:
> =
> Hello. How do you replicate bootable linux media, such as distribution=
> kits or just a bootable harddrive? I have been ransacking the HOWTOs,
> man pages, and lilo documentation but need a confirmation.
> Under LynxOS (TM) , I'm starting to forget, but I could use diskcopy to=
> copy the drive block by block, and makeboot to make the boot sector.
> The drives were identical removable media.
> But as to linux, I saw another note here that showed that I may have to=
> 1. partition the drive
> 2. make the file system
> 3. use lilo.conf and lilo to install the boot block
> 4. I guess I just mount the disk and do a recursive copy of everything =
I want
> on there.
> Is that about it? Are there instructions in the howtos on making boota=
ble
> cdroms?
To make a verbatim copy of a hard disk, you will need two drives with an
identical set of heads and sectors/track, because the partitioning (at
least on PC hardware) is cylinder based. The new disk must have enough
cylinders to cater for the used part of your original disk.
Then you can just dd the entire drive (e.g. /dev/hda or /dev/sda) to the
new drive (e.g. /dev/hdb or /dev/sdb). Make sure you umount as many
partitions as you can, and call sync before copying. The former will
save on fsck time and the latter will prevent major data loss.
You cannot use technique this to make a bootable CDROM because CDROMs
have different block sizes (2k vs. 512) and a different file system
structure than hard disks.
-- =
Josef M=F6llers (Pinguinpfleger bei FSC)
If failure had no penalty success would not be a prize (T. Pratchett)
------------------------------
From: "Christoph" <[EMAIL PROTECTED]>
Subject: How to control parallel port from user level?
Date: Thu, 2 Nov 2000 10:17:33 +0100
Hi,
I want to control the parallel port from user level. Unfortunately I can't
find ioperm which should be in unistd.h on i386 systems. Where is it?
Kind regards,
Christoph
------------------------------
From: [EMAIL PROTECTED]
Subject: verify_area(..) error
Date: Thu, 02 Nov 2000 09:33:26 GMT
Hi
In my linux device driver,I always encounter error when perform
verify_area(..) in white function. How can avoid it.
Thanx
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Kasper Dupont <[EMAIL PROTECTED]>
Subject: Re: Disk Replication (bootable)
Date: Thu, 02 Nov 2000 11:18:20 +0100
Josef Moellers wrote:
>
[...]
>
> You cannot use technique this to make a bootable CDROM because CDROMs
> have different block sizes (2k vs. 512) and a different file system
> structure than hard disks.
>
You can copy a bootable CDROM like any other CDROM.
Find the blockspecialfile for the device and copy
it to a file on your harddisk. This will be an image
that can be recorded using whatever cdrecorder program
you prefer.
If you want to create a bootable CDROM you should
first create a bootable floppy. If you don't need to
test the floppy you can make it using a ramdisk or a
loopback device. When the boot floppy is ready umont
it and copy it to an image (not necesarry if you used
loopback). There are multiple choices of image size,
including 1.44MB and 2.88MB, it does not have to match
your floppydrive unless you want to use the floppydrive
for testing.
Create the CD image using whatever program you prefer
(mkisofs, mkhybrid etc.) at this point you must specify
that the floppy image should be used as an El torito
boot image.
On boot the BIOS will emulate a floppy. Bootloader,
kernel and ramdisk image can be loaded from this
emulated floppy. When the Linux kernel starts booting
the emulated floppy will no longer exist, so root have
to be either a ramdisk loaded from the floppy or the
CD. (Using the CD is a litle tricky since you don't
know its device number.)
> --
> Josef M�llers (Pinguinpfleger bei FSC)
> If failure had no penalty success would not be a prize (T. Pratchett)
--
Kasper Dupont
------------------------------
From: Kasper Dupont <[EMAIL PROTECTED]>
Subject: Re: How to control parallel port from user level?
Date: Thu, 02 Nov 2000 11:23:43 +0100
Christoph wrote:
>
> Hi,
>
> I want to control the parallel port from user level. Unfortunately I can't
> find ioperm which should be in unistd.h on i386 systems. Where is it?
>
> Kind regards,
> Christoph
man ioperm says:
#include <unistd.h> /* for libc5 */
#include <sys/io.h> /* for glibc */
And also note that some of the macros in theese
header files needs optimizing to be enabled
otherwise it cannot compile.
--
Kasper Dupont
------------------------------
From: "U. Siegel" <[EMAIL PROTECTED]>
Subject: RAID5 under 2.4.0-test9
Date: Thu, 02 Nov 2000 12:48:45 +0100
Hi,
i'm trying hard to implement an RAID5 array under kernel-2.4.0-test9.
Creating the array was no problem, also mounting. But at the moment i
start writing to the array i get the following error messages:
EXT2-fs error (device md(9,0)): ext2_new_block: Allocating block in
system zone - block = xxxxxxxx
EXT2-fs error (device md(9,0)): ext2_free_blocks: Freeing blocks in
system zones - Blocks = yyyyyyy, count = z
My hardware configuration a Netfinity 5100 with 2 x PIII/933, 2GB RAM
and 5 IBM 9,1 GB HDD.
The raidtab looks like:
raiddev /dev/md0
raid-level 5
nr-raid-disks 3
nr-spare-disks 0
persistent-superblock 1
parity-algorithm left-symmetric
chunk-size 32
device /dev/sd[bcd]2
raid-disk [012]
Any suggestion, how to fix the problem?
------------------------------
From: "Francois Groenewald" <francois_at_figment_dot_co_dot_za>
Subject: Stacking Kernel Drivers
Date: Thu, 2 Nov 2000 14:32:06 +0200
Hi,
I'm not quite sure if this is the right place for this but here it goes.
I'm having a hard time developing a 'generic' transport layer that is
supposed to be a kernel mode driver layered above the following interfaces:
serial (modem, serial radio pad's), x25 (sangoma) and possible ip. The
reason I'm trying to make these kernel mode drivers is so that applications
can use normal file IO (open, close, ioctl etc) on these special 'devices' -
also it looked like more fun that doing a user mode daemon that gets talked
to by pipes etc.
How is layering done in the kernel ? I've been grepping through the
source and am none the wiser. I tried looking at the source for the
filesystem modules as these are obviously stacked but it seems they are
special in that regard. Is a generic stacking method available ? Or can I at
least open /dev/ttyS0 from within a kernel driver (if so, which function do
I use).
Thanks for reading,
Francois Groenewald
Figment Design Laboratories.
------------------------------
From: Andi Kleen <[EMAIL PROTECTED]>
Subject: Re: RFI: Linux implementation of tnf tracing system
Date: 02 Nov 2000 14:19:50 +0100
Kaelin Colclasure <[EMAIL PROTECTED]> writes:
> > Another possibility would be a shared memory segment
> > with a ring buffer per CPU that is only used for user space processes
> > (kernel needs a separate buffer because it should be accessed from
> > interrupts and that needs special locking) and does a simple user space l
> > ocking. Advantage: you can trace without needing relatively costly system
> > calls. The shared memory segment could be also maintained in the kernel
> > by supplying an mmap operation to the device driver.
>
> Uh, is that as complicated to implement as it sounds? :-) I'm thinking
> the buffer-per-CPU thing ktrace does is a really good idea -- but
> outside of kernel space how would I tell what CPU I'm running on?
> Without a syscall? And remember, I'm only up to Chapter 3 of LDD! :-)
I would not use per CPU buffers in the user space, just do a
simple spinlock. On big SMP machines that may be more costly than syscall
+ per cpu buffer, but on smaller SMP or UP I suspect it would be faster
because you save the syscall overhead.
An alternative would be per pid buffers, or at least per pid reservations
(grab 16 log entries for current pid with a log, fill them, etc.)
Disadvantage is that it is not secure. You would probably need a different
shm segment for every uid.
>
> > > Should I just forget the idea the kernel and user TNF_PROBES are
> > > going to be able to share the same implementation? Is there a
> > > better alternative that I don't know about?
> >
> > It is certainly possible, but it would be probably more efficient to not
> > do it.
> >
> > > 3) Is it reasonable to kalloc a 4MB or larger trace buffer, or do I
> > > need to consider a more sophisticated buffering strategy?
> >
> > You can vmalloc() such a buffer.
>
> Wow, VM in the kernel! You guys are losing your sheen of studliness...
> ;-) Thanks for the pointer.
It does not do what you think. It just allocates physical memory with
a virtual mapping in the kernel map so you see it as continuous, but it
is not swappable. It is only a way to get virtually continuous buffers
in spite of memory fragmentation.
-Andi
------------------------------
From: Bernd Strieder <[EMAIL PROTECTED]>
Subject: Re: Disk Replication (bootable)
Date: Thu, 02 Nov 2000 15:00:34 +0100
Josef Moellers wrote:
>
> Tom J wrote:
> >
> > Hello. How do you replicate bootable linux media, such as distribution
> > kits or just a bootable harddrive? I have been ransacking the HOWTOs,
> > man pages, and lilo documentation but need a confirmation.
> > Under LynxOS (TM) , I'm starting to forget, but I could use diskcopy to
> > copy the drive block by block, and makeboot to make the boot sector.
> > The drives were identical removable media.
> > But as to linux, I saw another note here that showed that I may have to
> > 1. partition the drive
> > 2. make the file system
> > 3. use lilo.conf and lilo to install the boot block
> > 4. I guess I just mount the disk and do a recursive copy of everything I want
> > on there.
> > Is that about it? Are there instructions in the howtos on making bootable
> > cdroms?
>
> To make a verbatim copy of a hard disk, you will need two drives with an
> identical set of heads and sectors/track, because the partitioning (at
> least on PC hardware) is cylinder based. The new disk must have enough
> cylinders to cater for the used part of your original disk.
> Then you can just dd the entire drive (e.g. /dev/hda or /dev/sda) to the
> new drive (e.g. /dev/hdb or /dev/sdb). Make sure you umount as many
> partitions as you can, and call sync before copying. The former will
> save on fsck time and the latter will prevent major data loss.
There are emergency kits on floppy or CD that contain all you need for
this job. This saves you from copying mounted partitions altogether and
the following annoyances.
I did this once for a series of 5 computers with all the same hardware.
Well, the harddisks differed a little in size, everything else was the
same. I installed the first system to be ready to use, then I mounted
another harddisk into it, booted a purely CD-based system and copied the
whole harddisk a la "dd if=/dev/hda of=/dev/hdb". Thus, the partition
table, boatloaders and their data were exactly copied. If this is not
possible (differing disks), you will definitly have to partition and
install the bootloader yourself, since only that way bootloader and
partiton table can be copied. Depending on the partition scheme you can
copy full partitions a la "dd if=/dev/hdxx of=/dev/hdxy". This is still
faster than copying file by file. When there is no pairwise unique
correlation between the partitions, you have to copy file by file a la
"cd /disk1-root/; cp -a ./ /disk2-root/". You have to use "-a" as option
to avoid problems with soft-, and hardlinks.
You have to check if it works in advance, if sizes of the disks or
partitions fit, even for the same model, if partition tables can be
copied,... It is generally easier to copy from smaller to bigger disks
or partitions, but in the case of partitions the copied filesystem image
will possibly not span the whole destiniation partition, another
annoyance. Perhaps there are filesystem image resizing possibilities.
Be sure to have an emergency kit available, and think twice before using
dd on partitions that way, since errors through dd are often not
recoverable from.
Taking in account all the possible problems, it may be the conclusion,
that copying directly is useful for replication of large series of
systems. In most other cases you'll possibly find problems and
annoyances that make it not being worth the hassle.
Bernd Strieder
------------------------------
From: [EMAIL PROTECTED] (Tom J)
Subject: Re: Disk Replication (bootable)
Date: Thu, 2 Nov 2000 14:45:25 GMT
Hi.
This is what I've been trying.
*1. the disks are different geometries (I misled you with an allusion to
something I did on LynxOS on magneto-optical media 5 years ago).
They are both hard drives but later I may try to build cd roms.
The booting drive is IDE primary master. I put the drive to be copied to as
secondary IDE master.
*2. Learn to partition the disk with sfdisk and cfdisk and do it
(a boot area, a swap area and the rest for files.).
*3. make file systems on the two file system areas:
mkfs -V -text2 -c /dev/hdc3 and hdc1
*3.5 mount /dev/hdc3 /mnt/hd2
*4. cpio --pass-through /mnt/hd2 < files.txt
The files.txt has everything in it except proc/*, dev/* and /mnt/hd2/ .
It turns out since the drive has only 512 cylinders I don't have to have a
boot partition, but anyway.
5. I am trying to make device nodes with MAKEDEV by
cp /dev/MAKEDEV /mnt/hd2/dev/
cd /mnt/hd2/dev/ ; ./MAKEDEV
but this doesn't work. I was assuming that I can't just copy device
nodes. Maybe I can.
6. So what if I edit /etc/lilo.conf
to add
image=/mnt/hd2/vmlinuz
label=linux
read-only
root=/mnt/hd2/dev/hda3
I mean, then the boot block will point to the wrong disk drives.
I want to be able to move the new disk drive to IDE primary master.
How can I install a boot block on a drive mounted at /mnt/hd2 that
it should boot from /vmlinuz?
I don't feel confident about using dd because how can the inodes from one
drive be right for a different geometry drive?
How can the boot information be right?
Should we just plan to copy identical geometry drives? I don't think that we
can do that in our situation of rehabilitating old dos equipment into linux
systems.
Thanks very much for you help so far!
--
Tom J.; tej at world.std.com Massachusetts USA; MSCS; Systems Programmer
Dist. Real-Time Data Acquisition S/W for Science and Eng. under POSIX,
C, C++, X, Motif, Graphics, Audio http://world.std.com/~tej
------------------------------
** FOR YOUR REFERENCE **
The service address, to which questions about the list itself and requests
to be added to or deleted from it should be directed, is:
Internet: [EMAIL PROTECTED]
You can send mail to the entire list (and comp.os.linux.development.system) via:
Internet: [EMAIL PROTECTED]
Linux may be obtained via one of these FTP sites:
ftp.funet.fi pub/Linux
tsx-11.mit.edu pub/linux
sunsite.unc.edu pub/Linux
End of Linux-Development-System Digest
******************************
