Re: [RFC PATCH] /sys/block -> /sys/class/block (Fedora 3 & 4 testers wanted)
Greg: A while back you asked whether Kay's block-device patch would work under FC3 or FC4. I've got an old FC4 system; the normal kernel-update procedure hasn't worked on it for some time. (I don't remember exactly when it stopped working.) Not for any sinister reason. The underlying problem seems to be that the nash script or the nash executable in the initramfs image created by RedHat's mkinitrd program in FC4 has a few errors. In particular, the "--movedev" option to the switchroot command doesn't work right. On the other hand, I customized that script for myself last year (only a few changes were needed) and have had no problems booting any kernel up to and including your current development tree. For the record, here is the script as created by FC4's last official update: #!/bin/nash mount -t proc /proc /proc setquiet echo Mounted /proc filesystem echo Mounting sysfs mount -t sysfs /sys /sys echo Creating /dev mount -o mode=0755 -t tmpfs /dev /dev mknod /dev/console c 5 1 mknod /dev/null c 1 3 mknod /dev/zero c 1 5 mkdir /dev/pts mkdir /dev/shm echo Starting udev /sbin/udevstart echo -n "/sbin/hotplug" > /proc/sys/kernel/hotplug echo "Loading jbd.ko module" insmod /lib/jbd.ko echo "Loading ext3.ko module" insmod /lib/ext3.ko /sbin/udevstart echo Creating root device mkrootdev /dev/root echo Mounting root filesystem mount -o defaults --ro -t ext3 /dev/root /sysroot echo Switching to new root switchroot --movedev /sysroot Don't ask me why udevstart is called twice -- it works okay under FC4's 2.6.17 kernel. Here is the diff for my customized version: --- norm/init 2007-06-03 14:02:58.0 -0400 +++ test/init 2007-06-03 14:01:13.0 -0400 @@ -22,7 +22,10 @@ /sbin/udevstart echo Creating root device mkrootdev /dev/root +umount /sys echo Mounting root filesystem mount -o defaults --ro -t ext3 /dev/root /sysroot +mount -t tmpfs --bind /dev /sysroot/dev echo Switching to new root -switchroot --movedev /sysroot +switchroot /sysroot +umount /initrd/dev In all honesty, I should mention that the versions of nash and udev in my customized initramfs image aren't the same as the ones in the FC4 image. They are derived from FC6; in fact I use the same initramfs image for testing new kernels under both FC4 and FC6. Also the contents of etc/udev/udev.conf differ in the two images. Alan Stern - 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/
Re: [RFC PATCH] /sys/block -> /sys/class/block (Fedora 3 & 4 testers wanted)
On Thu, 2007-05-24 at 00:35 +0400, Michael Tokarev wrote:
> Greg KH wrote:
> []
> > From: Kay Sievers <[EMAIL PROTECTED]>
> > Subject: Driver core: convert block from raw kobjects to core devices
> >
> > This moves the block devices to /sys/class/block. It will create a
> > flat list of all block devices, with the disks and partitions in one
> > directory. For compatibility /sys/block is created and contains symlinks
> > to the disks.
>
> What's the proper way now to figure out which device type it is --
> block or char?
>From the "subsystem" value of the device, only if it's "block" it's a
block node, everything else is a char node.
> Before, I had a function (in my udev-alike userspace app), something akin
> sysfs_scan_devices(char *topdir, mode_t type), and called it twice --
>
> sysfs_scan_devices("/block", S_IFBLK);
> sysfs_scan_devices("/devices", S_IFCHR);
>
> How it's supposed to work now?
You need to resolve the symlink, back to the originating subsystem the
device belongs to.
Just better read the flat directories /sys/bus/*/devices/*, /sys/class/*/*,
and you get the subsystem values for free, instead of searching through
the directory tree in /sys/devices/.
> (Note that it skips symlinks for obvious
> reason, hence it can't find anything in /sys/block, even with the compat
> "layer" in place)
Everything can be a symlink or a directory, you can't assume one or the
other. You better start from the buses and classes. The udevtrigger code
or the HAL coldplug code work with all versions of sysfs, just look at
these as an example.
Thanks,
Kay
-
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/
Re: [RFC PATCH] /sys/block -> /sys/class/block (Fedora 3 & 4 testers wanted)
On Wed, 23 May 2007 11:08:42 -0700, Greg KH <[EMAIL PROTECTED]> wrote: > Ok, yeah, that is wierd. > > Kay found the problem (he's traveling right now) and here's his updated > version of the patch which should work for everyone involved. > > Please let me know if this causes any problems or not. Ah, this seems to work fine now (both with and without CONFIG_SYSFS_DEPRECATED; when it is set, even lsdasd seems happy). Thanks! - 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/
Re: [RFC PATCH] /sys/block -> /sys/class/block (Fedora 3 & 4 testers wanted)
Greg KH wrote:
[]
> From: Kay Sievers <[EMAIL PROTECTED]>
> Subject: Driver core: convert block from raw kobjects to core devices
>
> This moves the block devices to /sys/class/block. It will create a
> flat list of all block devices, with the disks and partitions in one
> directory. For compatibility /sys/block is created and contains symlinks
> to the disks.
What's the proper way now to figure out which device type it is --
block or char?
Before, I had a function (in my udev-alike userspace app), something akin
sysfs_scan_devices(char *topdir, mode_t type), and called it twice --
sysfs_scan_devices("/block", S_IFBLK);
sysfs_scan_devices("/devices", S_IFCHR);
How it's supposed to work now? (Note that it skips symlinks for obvious
reason, hence it can't find anything in /sys/block, even with the compat
"layer" in place)
(Not complaining, but asking instead)
Thanks.
/mjt
-
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/
Re: [RFC PATCH] /sys/block -> /sys/class/block (Fedora 3 & 4 testers wanted)
Greg KH wrote:
[]
> From: Kay Sievers <[EMAIL PROTECTED]>
> Subject: Driver core: convert block from raw kobjects to core devices
>
> This moves the block devices to /sys/class/block. It will create a
> flat list of all block devices, with the disks and partitions in one
> directory. For compatibility /sys/block is created and contains symlinks
> to the disks.
What's the proper way now to figure out which device type it is --
block or char?
Before, I had a function (in my udev-alike userspace app), something akin
sysfs_scan_devices(char *topdir, mode_t type), and called it twice --
sysfs_scan_devices("/block", S_IFBLK);
sysfs_scan_devices("/devices", S_IFCHR);
How it's supposed to work now? (Note that it skips symlinks for obvious
reason, hence it can't find anything in /sys/block, even with the compat
"layer" in place)
(Not complaining, but asking instead)
Thanks.
/mjt
-
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/
Re: [RFC PATCH] /sys/block -> /sys/class/block (Fedora 3 & 4 testers wanted)
On Wed, May 23, 2007 at 07:39:59AM +0200, Cornelia Huck wrote: > On Tue, 22 May 2007 17:32:55 -0700, > Greg KH <[EMAIL PROTECTED]> wrote: > > > On Tue, May 22, 2007 at 06:28:12PM +0200, Cornelia Huck wrote: > > > On Tue, 22 May 2007 10:25:01 +0200, > > > Cornelia Huck <[EMAIL PROTECTED]> wrote: > > > > > > > I tried this on one of our internal drivers, which is based on FC 3 (or > > > > 4, can look this up). With s390 defconfig, it is unable to open the > > > > root device /dev/dasda1 (which is unsurprising, considering udev (063) > > > > decided to create /dev/dasda(1) as a character node instead of a block > > > > node). > > > > > > Just to be clear, it's fsck that complains: > > > > > > Checking filesystems > > > Checking all file systems. > > > [/sbin/fsck.ext3 (1) -- /] fsck.ext3 -a /dev/dasda1 > > > fsck.ext3: No such device or address while trying to open /dev/dasda1 > > > Possibly non-existent or swap device? > > > [FAILED] > > > > > > (so that is after udev has been started and obviously dasda1 could be > > > accessed) > > > > But /dev/dasda1 isn't present? Or why would fsck be complaining here? > > See above. /dev/dasda1 exists, but strangely as a character device, > which makes fsck unhappy. > > > > > > > When I look at the system, /sys/block/ and /sys/class/block/ look sane > > > > at first glance (working on a 3270 console is usally PITA...) > > > > > > > > Even more surprisingly, the system comes up fine (once I added ptmx to > > > > makedev.d/) with CONFIG_SYSFS_DEPRECATED not set. /sys/block/ > > > > and /sys/class/block/ look just like expected. (Unfortunately, our > > > > lsdasd tool breaks with this...) > > > > > > > > I'll see if I can find out more. > > > > > > I currently have the inkling that > > > > > > lrwxrwxrwx 1 root root0 May 22 15:59 block:dasda1-> > > > ../../../class/block/dasda1 > > > > > > in /sys/block/dasda/ is the culprit. > > > > Why? > > See the paragraph just below, but it's more like a hunch currently. > > > > > > In all other versions I've tried (without CONFIG_SYSFS_DEPRECATED, and > > > on an older kernel with and without CONFIG_SYSFS_DEPRECATED), it's > > > always dasda1. > > > > That's just a back symlink, the real device should still be there. > > It is, but somehow udev seems confused. > > > > > Oh, and yes, you will probably have to have CONFIG_SYSFS_DEPRECATED > > enabaled to have a chance for these to work on Fedora 4 or 3. > > Hmpf. That's just the problem :) > > - enable CONFIG_SYSFS_DEPRECATED: fails as described > - disable CONFIG_SYSFS_DEPRECATED: works > > If one of the two was to fail, I'd rather expect it the other way > around... Ok, yeah, that is wierd. Kay found the problem (he's traveling right now) and here's his updated version of the patch which should work for everyone involved. Please let me know if this causes any problems or not. thanks, greg k-h From: Kay Sievers <[EMAIL PROTECTED]> Subject: Driver core: convert block from raw kobjects to core devices This moves the block devices to /sys/class/block. It will create a flat list of all block devices, with the disks and partitions in one directory. For compatibility /sys/block is created and contains symlinks to the disks. /sys/class/block |-- sda -> ../../devices/pci:00/:00:1f.2/host0/target0:0:0/0:0:0:0/block/sda |-- sda1 -> ../../devices/pci:00/:00:1f.2/host0/target0:0:0/0:0:0:0/block/sda/sda1 |-- sda10 -> ../../devices/pci:00/:00:1f.2/host0/target0:0:0/0:0:0:0/block/sda/sda10 |-- sda5 -> ../../devices/pci:00/:00:1f.2/host0/target0:0:0/0:0:0:0/block/sda/sda5 |-- sda6 -> ../../devices/pci:00/:00:1f.2/host0/target0:0:0/0:0:0:0/block/sda/sda6 |-- sda7 -> ../../devices/pci:00/:00:1f.2/host0/target0:0:0/0:0:0:0/block/sda/sda7 |-- sda8 -> ../../devices/pci:00/:00:1f.2/host0/target0:0:0/0:0:0:0/block/sda/sda8 |-- sda9 -> ../../devices/pci:00/:00:1f.2/host0/target0:0:0/0:0:0:0/block/sda/sda9 `-- sr0 -> ../../devices/pci:00/:00:1f.2/host1/target1:0:0/1:0:0:0/block/sr0 /sys/block/ |-- sda -> ../devices/pci:00/:00:1f.2/host0/target0:0:0/0:0:0:0/block/sda `-- sr0 -> ../devices/pci:00/:00:1f.2/host1/target1:0:0/1:0:0:0/block/sr0 Signed-off-by: Kay Sievers <[EMAIL PROTECTED]> Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]> --- block/genhd.c | 413 ++--- block/ll_rw_blk.c |4 drivers/base/core.c| 16 + drivers/block/aoe/aoeblk.c | 51 ++--- drivers/block/nbd.c| 15 - drivers/ide/ide-probe.c|2 drivers/md/dm.c|2 drivers/md/md.c|8 fs/block_dev.c |8 fs/partitions/check.c | 304 +++-- include/linux/genhd.h | 23 +- init/do_mounts.c | 108 --- 12 files changed, 359 insertions(+), 595 deletions(-) --- a/block/g
Re: [RFC PATCH] /sys/block -> /sys/class/block (Fedora 3 & 4 testers wanted)
On Tue, 22 May 2007 17:32:55 -0700, Greg KH <[EMAIL PROTECTED]> wrote: > On Tue, May 22, 2007 at 06:28:12PM +0200, Cornelia Huck wrote: > > On Tue, 22 May 2007 10:25:01 +0200, > > Cornelia Huck <[EMAIL PROTECTED]> wrote: > > > > > I tried this on one of our internal drivers, which is based on FC 3 (or > > > 4, can look this up). With s390 defconfig, it is unable to open the > > > root device /dev/dasda1 (which is unsurprising, considering udev (063) > > > decided to create /dev/dasda(1) as a character node instead of a block > > > node). > > > > Just to be clear, it's fsck that complains: > > > > Checking filesystems > > Checking all file systems. > > [/sbin/fsck.ext3 (1) -- /] fsck.ext3 -a /dev/dasda1 > > fsck.ext3: No such device or address while trying to open /dev/dasda1 > > Possibly non-existent or swap device? > > [FAILED] > > > > (so that is after udev has been started and obviously dasda1 could be > > accessed) > > But /dev/dasda1 isn't present? Or why would fsck be complaining here? See above. /dev/dasda1 exists, but strangely as a character device, which makes fsck unhappy. > > > > When I look at the system, /sys/block/ and /sys/class/block/ look sane > > > at first glance (working on a 3270 console is usally PITA...) > > > > > > Even more surprisingly, the system comes up fine (once I added ptmx to > > > makedev.d/) with CONFIG_SYSFS_DEPRECATED not set. /sys/block/ > > > and /sys/class/block/ look just like expected. (Unfortunately, our > > > lsdasd tool breaks with this...) > > > > > > I'll see if I can find out more. > > > > I currently have the inkling that > > > > lrwxrwxrwx 1 root root0 May 22 15:59 block:dasda1-> > > ../../../class/block/dasda1 > > > > in /sys/block/dasda/ is the culprit. > > Why? See the paragraph just below, but it's more like a hunch currently. > > > In all other versions I've tried (without CONFIG_SYSFS_DEPRECATED, and > > on an older kernel with and without CONFIG_SYSFS_DEPRECATED), it's > > always dasda1. > > That's just a back symlink, the real device should still be there. It is, but somehow udev seems confused. > > Oh, and yes, you will probably have to have CONFIG_SYSFS_DEPRECATED > enabaled to have a chance for these to work on Fedora 4 or 3. Hmpf. That's just the problem :) - enable CONFIG_SYSFS_DEPRECATED: fails as described - disable CONFIG_SYSFS_DEPRECATED: works If one of the two was to fail, I'd rather expect it the other way around... > > > I can continue investigating tomorrow, unless someone has a good idea :) > > I don't, but any information you can find out would be greatly > appreciated, especially as it seems like it is working, but something is > still a little bit wrong. It's not really according to my definition of "working" :) But yes, I'll see what I can do. - 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/
Re: [RFC PATCH] /sys/block -> /sys/class/block (Fedora 3 & 4 testers wanted)
On Tue, May 22, 2007 at 06:28:12PM +0200, Cornelia Huck wrote: > On Tue, 22 May 2007 10:25:01 +0200, > Cornelia Huck <[EMAIL PROTECTED]> wrote: > > > I tried this on one of our internal drivers, which is based on FC 3 (or > > 4, can look this up). With s390 defconfig, it is unable to open the > > root device /dev/dasda1 (which is unsurprising, considering udev (063) > > decided to create /dev/dasda(1) as a character node instead of a block > > node). > > Just to be clear, it's fsck that complains: > > Checking filesystems > Checking all file systems. > [/sbin/fsck.ext3 (1) -- /] fsck.ext3 -a /dev/dasda1 > fsck.ext3: No such device or address while trying to open /dev/dasda1 > Possibly non-existent or swap device? > [FAILED] > > (so that is after udev has been started and obviously dasda1 could be > accessed) But /dev/dasda1 isn't present? Or why would fsck be complaining here? > > When I look at the system, /sys/block/ and /sys/class/block/ look sane > > at first glance (working on a 3270 console is usally PITA...) > > > > Even more surprisingly, the system comes up fine (once I added ptmx to > > makedev.d/) with CONFIG_SYSFS_DEPRECATED not set. /sys/block/ > > and /sys/class/block/ look just like expected. (Unfortunately, our > > lsdasd tool breaks with this...) > > > > I'll see if I can find out more. > > I currently have the inkling that > > lrwxrwxrwx 1 root root0 May 22 15:59 block:dasda1-> > ../../../class/block/dasda1 > > in /sys/block/dasda/ is the culprit. Why? > In all other versions I've tried (without CONFIG_SYSFS_DEPRECATED, and > on an older kernel with and without CONFIG_SYSFS_DEPRECATED), it's > always dasda1. That's just a back symlink, the real device should still be there. Oh, and yes, you will probably have to have CONFIG_SYSFS_DEPRECATED enabaled to have a chance for these to work on Fedora 4 or 3. > I can continue investigating tomorrow, unless someone has a good idea :) I don't, but any information you can find out would be greatly appreciated, especially as it seems like it is working, but something is still a little bit wrong. thanks, greg k-h - 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/
Re: [RFC PATCH] /sys/block -> /sys/class/block (Fedora 3 & 4 testers wanted)
On Tue, 22 May 2007 10:25:01 +0200, Cornelia Huck <[EMAIL PROTECTED]> wrote: > I tried this on one of our internal drivers, which is based on FC 3 (or > 4, can look this up). With s390 defconfig, it is unable to open the > root device /dev/dasda1 (which is unsurprising, considering udev (063) > decided to create /dev/dasda(1) as a character node instead of a block > node). Just to be clear, it's fsck that complains: Checking filesystems Checking all file systems. [/sbin/fsck.ext3 (1) -- /] fsck.ext3 -a /dev/dasda1 fsck.ext3: No such device or address while trying to open /dev/dasda1 Possibly non-existent or swap device? [FAILED] (so that is after udev has been started and obviously dasda1 could be accessed) > When I look at the system, /sys/block/ and /sys/class/block/ look sane > at first glance (working on a 3270 console is usally PITA...) > > Even more surprisingly, the system comes up fine (once I added ptmx to > makedev.d/) with CONFIG_SYSFS_DEPRECATED not set. /sys/block/ > and /sys/class/block/ look just like expected. (Unfortunately, our > lsdasd tool breaks with this...) > > I'll see if I can find out more. I currently have the inkling that lrwxrwxrwx 1 root root0 May 22 15:59 block:dasda1-> ../../../class/block/dasda1 in /sys/block/dasda/ is the culprit. In all other versions I've tried (without CONFIG_SYSFS_DEPRECATED, and on an older kernel with and without CONFIG_SYSFS_DEPRECATED), it's always dasda1. I can continue investigating tomorrow, unless someone has a good idea :) - 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/
Re: [RFC PATCH] /sys/block -> /sys/class/block (Fedora 3 & 4 testers wanted)
On Mon, 21 May 2007 16:53:53 -0700, Greg KH <[EMAIL PROTECTED]> wrote: > So, could anyone still running the crufty and unsupported Fedora 3 and 4 > releases test this patch out and let us know if it boots your machine or > not? I don't want to break legacy distros if we can possibly help it. > > This has been successfully tested on both SuSE and Gentoo boxes, so > we do hope this works for others. Unfortunately, it doesn't :( I tried this on one of our internal drivers, which is based on FC 3 (or 4, can look this up). With s390 defconfig, it is unable to open the root device /dev/dasda1 (which is unsurprising, considering udev (063) decided to create /dev/dasda(1) as a character node instead of a block node). The only udev rule I found which could affect the dasd device nodes is SUBSYSTEM=="block", GROUP="disk", MODE="0640" When I look at the system, /sys/block/ and /sys/class/block/ look sane at first glance (working on a 3270 console is usally PITA...) Even more surprisingly, the system comes up fine (once I added ptmx to makedev.d/) with CONFIG_SYSFS_DEPRECATED not set. /sys/block/ and /sys/class/block/ look just like expected. (Unfortunately, our lsdasd tool breaks with this...) I'll see if I can find out more. - 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/
[RFC PATCH] /sys/block -> /sys/class/block (Fedora 3 & 4 testers wanted)
Here's a patch from Kay that has been knocking around in my personal
tree for about 6 months. It moves the block code to use 'struct device'
and moves the tree from /sys/block into /sys/class/block.
Now don't everyone fret, there are still symlinks in /sys/block to the
new entries, so older userspaces _should_ still work, but we aren't
quite sure yet. There might be some old udev rules that get tripped up
by this change, and if libsysfs is involved, all bets are off...
So, could anyone still running the crufty and unsupported Fedora 3 and 4
releases test this patch out and let us know if it boots your machine or
not? I don't want to break legacy distros if we can possibly help it.
This has been successfully tested on both SuSE and Gentoo boxes, so
we do hope this works for others.
thanks,
greg k-h
--
From: Kay Sievers <[EMAIL PROTECTED]>
Subject: Driver core: convert block from raw kobjects to core devices
This moves the block devices to /sys/class/block. It will create a
flat list of all block devices, with the disks and partitions in one
directory. For compatibility /sys/block is created and contains symlinks
to the disks.
/sys/class/block
|-- sda ->
../../devices/pci:00/:00:1f.2/host0/target0:0:0/0:0:0:0/block/sda
|-- sda1 ->
../../devices/pci:00/:00:1f.2/host0/target0:0:0/0:0:0:0/block/sda/sda1
|-- sda10 ->
../../devices/pci:00/:00:1f.2/host0/target0:0:0/0:0:0:0/block/sda/sda10
|-- sda5 ->
../../devices/pci:00/:00:1f.2/host0/target0:0:0/0:0:0:0/block/sda/sda5
|-- sda6 ->
../../devices/pci:00/:00:1f.2/host0/target0:0:0/0:0:0:0/block/sda/sda6
|-- sda7 ->
../../devices/pci:00/:00:1f.2/host0/target0:0:0/0:0:0:0/block/sda/sda7
|-- sda8 ->
../../devices/pci:00/:00:1f.2/host0/target0:0:0/0:0:0:0/block/sda/sda8
|-- sda9 ->
../../devices/pci:00/:00:1f.2/host0/target0:0:0/0:0:0:0/block/sda/sda9
`-- sr0 ->
../../devices/pci:00/:00:1f.2/host1/target1:0:0/1:0:0:0/block/sr0
/sys/block/
|-- sda ->
../devices/pci:00/:00:1f.2/host0/target0:0:0/0:0:0:0/block/sda
`-- sr0 ->
../devices/pci:00/:00:1f.2/host1/target1:0:0/1:0:0:0/block/sr0
Signed-off-by: Kay Sievers <[EMAIL PROTECTED]>
Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]>
---
block/genhd.c | 413 ++---
block/ll_rw_blk.c |4
drivers/base/core.c|2
drivers/block/aoe/aoeblk.c | 51 ++---
drivers/block/nbd.c| 15 -
drivers/ide/ide-probe.c|2
drivers/md/dm.c|2
drivers/md/md.c|8
fs/block_dev.c |8
fs/partitions/check.c | 300 +++-
include/linux/genhd.h | 23 +-
init/do_mounts.c | 108 ---
12 files changed, 344 insertions(+), 592 deletions(-)
--- a/block/genhd.c
+++ b/block/genhd.c
@@ -17,8 +17,12 @@
#include
#include
-struct kset block_subsys;
-static DEFINE_MUTEX(block_subsys_lock);
+extern struct class block_class;
+extern struct device_type disk_type;
+extern struct device_type part_type;
+
+static DEFINE_MUTEX(block_class_lock);
+struct kobject block_depr;
/*
* Can be deleted altogether. Later.
@@ -37,19 +41,17 @@ static inline int major_to_index(int maj
}
#ifdef CONFIG_PROC_FS
-
void blkdev_show(struct seq_file *f, off_t offset)
{
struct blk_major_name *dp;
if (offset < BLKDEV_MAJOR_HASH_SIZE) {
- mutex_lock(&block_subsys_lock);
+ mutex_lock(&block_class_lock);
for (dp = major_names[offset]; dp; dp = dp->next)
seq_printf(f, "%3d %s\n", dp->major, dp->name);
- mutex_unlock(&block_subsys_lock);
+ mutex_unlock(&block_class_lock);
}
}
-
#endif /* CONFIG_PROC_FS */
int register_blkdev(unsigned int major, const char *name)
@@ -57,7 +59,7 @@ int register_blkdev(unsigned int major,
struct blk_major_name **n, *p;
int index, ret = 0;
- mutex_lock(&block_subsys_lock);
+ mutex_lock(&block_class_lock);
/* temporary */
if (major == 0) {
@@ -102,7 +104,7 @@ int register_blkdev(unsigned int major,
kfree(p);
}
out:
- mutex_unlock(&block_subsys_lock);
+ mutex_unlock(&block_class_lock);
return ret;
}
@@ -116,7 +118,7 @@ int unregister_blkdev(unsigned int major
int index = major_to_index(major);
int ret = 0;
- mutex_lock(&block_subsys_lock);
+ mutex_lock(&block_class_lock);
for (n = &major_names[index]; *n; n = &(*n)->next)
if ((*n)->major == major)
break;
@@ -126,7 +128,7 @@ int unregister_blkdev(unsigned int major
p = *n;
*n = p->next;
}
- mutex_unlock(&block_subsys_lock);
+ mutex_unlock(&block_class_lock);
kfree(p);
return ret;
