[prev in list] [next in list] [prev in thread] [next in thread] 

List:       busybox
Subject:    Re: proc infrastructure
From:       Rob Landley <rob () landley ! net>
Date:       2006-02-25 16:35:19
Message-ID: 200602251135.19766.rob () landley ! net
[Download RAW message or body]

On Saturday 25 February 2006 12:17 am, Garrett Kajmowicz wrote:
> Are there any cases for which /proc is mounted but there is
> no /proc/ide/hdx/media entry for an ide device on the system?

On a 2.4 or later kernel?

I suppose if there aren't any IDE devices in the system, or if the kernel 
hasn't got the IDE driver...

> Do we actualy care about any of these?

Not crashing when there are no IDE devices in the system?  Yes.  Doing 
anything fancy with IDE devices when we can't get information about them?  
Probably not.

I presume you're querying drive geometry.  The correct thing to do is probably 
look at how the hdparm applet does it.  (In fact, if that code could be put 
in libbb and re-used...)  Of course glancing at hdparm.c, I see some code 
that could be trimmed out from there, too.  (fromhex(), GET_NUMBER(), 
GET_STRING()...)  I'm avoiding that can of worms for right now, though... :)  
But anyway, that seems to be using an ioctl() to get it, rather than /proc.

Drive geometry is becoming more and more of an abstraction these days.  Modern 
bioses no longer care (they use LBA), and Linux certainly doesn't care.  (If 
the partitions don't end on cylinder boundaries, Linux is quite happy with 
that).  I don't know if modern versions of Windows care or not, I don't use 
it.  (It's interesting to note that if you run QEMU on an unpartitioned image 
file, which has no geometry, it assumes 16 heads, 63 sectors, and however 
many cylinders can fit in that space.  If you can't detect the drive geometry, 
neither from the hardware, nor from any existing partition table, nor from 
the command line, that might be a reasonable default...)

One place it does still come up is bootloaders, which fit in the gap between 
the boot sector (sector zero) and the start of the first data partition 
(which starts $SECTORS into the disk, so with a C/H/S where S=63, hda1 will 
start at sector 64).

Yes, I had to learn all this crud to make bootable partitioned disk image 
files for qemu a few months back.  Some of the scripts I made during this 
process are attached, in case they're informative...

But five or six years ago I wrote a script to grab the disk geometry 
from /proc and manually partition the drive (through sfdisk) by calculating 
all the starting sectors for each one.  (List how big each partition should 
be in megabytes and it would round up to the next cylinder size.  The math 
was pretty straightforward.  Implemented in bash.  I might still have it 
lying around somewhere...)  That was for an embedded system manufacturing 
process...

Partitioning is not brain surgery...

> -      Garrett

Rob
-- 
Never bet against the cheap plastic solution.

["mkhda.sh" (application/x-shellscript)]

#!/bin/sh

# Now make a partitioned hard drive image file that qemu can boot.

CYLINDERS=64
HEADS=16
SECTORS=63
START=1

dd if=/dev/zero of=hda.img bs=$[$HEADS*$SECTORS*512] count=$CYLINDERS &&
#sfdisk -uS -C $CYLINDERS -H $HEADS -S $SECTORS  hda.img << EOF &&
#$START,$[$HEADS*SECTORS*$CYLINDERS-1],83
#EOF

# This is going to give an error because busybox fdisk is stupid and can't be
# told not to call the reread partition table IOCTL.

fdisk -C $CYLINDERS -H $HEADS -S $SECTORS hda.img << EOF
c
n
p
1


w
EOF

# Attach loop1 to whole disk, loop2 to first partition
losetup /dev/loop1 hda.img &&
losetup -o $[$START*512] /dev/loop2 hda.img &&
# Block size 1024 so sectors size is sectors/2
mke2fs -F /dev/loop2 -b 1024 $[$[$CYLINDERS*$HEADS*$SECTORS-$START]/2] &&
tune2fs -c 0 -i 0 /dev/loop2 &&
mount -t ext2 /dev/loop2 sub &&
cp ../firmware-boot sub &&

# Run lilo against image

LENGTH=`dd if=sub/firmware-boot skip=12 bs=1 count=4 2> /dev/null | od -l | head -n 1 \
| awk '{print $2}'` && cat > sub/lilo.conf << EOF &&
boot=/dev/loop1
compact
delay=10
timeout=999
disk=/dev/loop1
  bios=0x80
  cylinders=128
  heads=16
  sectors=63
  partition=/dev/loop2
    start=1

image=sub/firmware-boot
        label=linux
        root=/dev/loop2
        length=$LENGTH
        append="FIRMWARE=hda/hda1:firmware-boot"
        read-write
EOF
lilo -C sub/lilo.conf -m sub/lilo.map -s sub/bootage &&
umount sub &&
losetup -d /dev/loop1 &&
# Busybox umount will have detached this already.  Non-busybox umount won't.  I
# could supply -D to umount, but non-busybox umount wouldn't know what that is.
losetup -d /dev/loop2 2> /dev/null


["find_partition.sh" (application/x-shellscript)]

#!/bin/sh

x=1
while true
do
  echo $x
  losetup /dev/loop1 hda.img -o $[512*$x]
  mount /dev/loop1 sub
  if [ $? -eq 0 ]; then exit 0; fi
  losetup -d /dev/loop1
  x=$[1+$x]
done


_______________________________________________
busybox mailing list
busybox@busybox.net
http://busybox.net/cgi-bin/mailman/listinfo/busybox

[prev in list] [next in list] [prev in thread] [next in thread]