* Re: New rule for xD FTL driver
From: Greg KH @ 2010-06-15 15:47 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <1276347244.4481.15.camel@maxim-laptop>
On Tue, Jun 15, 2010 at 06:27:35PM +0300, Maxim Levitsky wrote:
> On Tue, 2010-06-15 at 07:55 -0700, Greg KH wrote:
> > On Tue, Jun 15, 2010 at 04:22:24PM +0300, Maxim Levitsky wrote:
> > > On Tue, 2010-06-15 at 11:28 +0100, David Woodhouse wrote:
> > > > On Tue, 2010-06-15 at 13:07 +0300, Maxim Levitsky wrote:
> > > > > Maybe not statically linked in it, but I am not against making mtd core
> > > > > load all compiled FTL drivers as soon as an mtd device is registred.
> > > > >
> > > > > David Woodhouse, what do you think about that?
> > > >
> > > > I'm not massively keen on that. An FTL is like a file system. Would you
> > > > insist on loading all compiled file systems when an mtd device is
> > > > registered?
> > > >
> > > > Would you submit udev patches which auto-load btrfs when a block device
> > > > is registered, such as the patch I see in the mail to which I'm
> > > > replying?
> > >
> > > This is very good point.
> > > The correct solution therefore is to create a new probe tool to look at
> > > new mtd device to see the 'filesystem magic', and them load the
> > > corresponding FTL.
> >
> > Yes, that sounds like the correct thing to do.
> >
> > > However, this still requires mtdchar or mtdblock be present.
> > > I think its not a bad idea to make mtdchar to load automatically on mtd
> > > device addition, and then bind the prober to creation of /dev/mtd0...
> > > (Which sure will be an udev rule)
> > >
> > > This is a bit out of my reach now because I am quite busy with exams, so
> > > for now, it would be nice to have this udev rule (so users won't tell me
> > > that my driver doesn't work), and later I sure fix that.
> >
> > No, as you pointed out, this is not the correct thing, so why would we
> > want to add it this way?
> A temporarily solution which is also more or less ok.
If it is "ok", and a "temporary" solution, then just move your kernel
module into the core mtd.ko module and you should be fine.
But odds are, you will not convince the mtd maintainer that's an ok
solution either :)
thanks,
greg k-h
^ permalink raw reply
* Re: New rule for xD FTL driver
From: Greg KH @ 2010-06-15 16:05 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <1276347244.4481.15.camel@maxim-laptop>
On Tue, Jun 15, 2010 at 06:45:48PM +0300, Maxim Levitsky wrote:
> Can udev helper tell udev to load modules by setting some variable?
Not really, except for the modalias stuff. Use that if you can.
But I think you've pointed out the real solution already. You need to
look at the signature on the device and then know what to load, just
like we do for filesystems.
good luck,
greg k-h
^ permalink raw reply
* Re: New rule for xD FTL driver
From: David Woodhouse @ 2010-06-15 17:01 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <1276347244.4481.15.camel@maxim-laptop>
On Tue, 2010-06-15 at 09:05 -0700, Greg KH wrote:
> On Tue, Jun 15, 2010 at 06:45:48PM +0300, Maxim Levitsky wrote:
> > Can udev helper tell udev to load modules by setting some variable?
>
> Not really, except for the modalias stuff. Use that if you can.
>
> But I think you've pointed out the real solution already. You need to
> look at the signature on the device and then know what to load, just
> like we do for filesystems.
Except we don't do that for file systems. We require an explicit mount
call, and all fstype probing is done in userspace.
--
dwmw2
^ permalink raw reply
* Re: New rule for xD FTL driver
From: Greg KH @ 2010-06-15 17:19 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <1276347244.4481.15.camel@maxim-laptop>
On Tue, Jun 15, 2010 at 06:01:31PM +0100, David Woodhouse wrote:
> On Tue, 2010-06-15 at 09:05 -0700, Greg KH wrote:
> > On Tue, Jun 15, 2010 at 06:45:48PM +0300, Maxim Levitsky wrote:
> > > Can udev helper tell udev to load modules by setting some variable?
> >
> > Not really, except for the modalias stuff. Use that if you can.
> >
> > But I think you've pointed out the real solution already. You need to
> > look at the signature on the device and then know what to load, just
> > like we do for filesystems.
>
> Except we don't do that for file systems. We require an explicit mount
> call, and all fstype probing is done in userspace.
True.
So, what do you suggest for how to know how to load the individual mtd
drivers?
thanks,
greg k-h
^ permalink raw reply
* Re: New rule for xD FTL driver
From: Maxim Levitsky @ 2010-06-15 17:46 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <1276347244.4481.15.camel@maxim-laptop>
On Tue, 2010-06-15 at 09:05 -0700, Greg KH wrote:
> On Tue, Jun 15, 2010 at 06:45:48PM +0300, Maxim Levitsky wrote:
> > Can udev helper tell udev to load modules by setting some variable?
>
> Not really, except for the modalias stuff. Use that if you can.
>
> But I think you've pointed out the real solution already. You need to
> look at the signature on the device and then know what to load, just
> like we do for filesystems.
>
> good luck,
>
> greg k-h
It seems to work just fine.
mtdchar I see it loaded automatically anyway due to char device alias.
So this rules does the trick:
ACTION!="add", GOTO="mtd_probe_end"
KERNEL="mtd*ro", IMPORT{program}="mtd_probe --export $tempnode"
LABEL="mtd_probe_end"
And all I have to do is to write the mtd_probe
My current stub mtd-probe is:
#!/bin/sh
# $1 = device node
echo "MODALIAS=sm_ftl"
echo "ID_DRIVE_FLASH=1"
Best regards,
Maxim Levitsky
^ permalink raw reply
* Re: New rule for xD FTL driver
From: Kay Sievers @ 2010-06-15 19:02 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <1276347244.4481.15.camel@maxim-laptop>
On Tue, Jun 15, 2010 at 19:46, Maxim Levitsky <maximlevitsky@gmail.com> wrote:
> On Tue, 2010-06-15 at 09:05 -0700, Greg KH wrote:
>> On Tue, Jun 15, 2010 at 06:45:48PM +0300, Maxim Levitsky wrote:
>> > Can udev helper tell udev to load modules by setting some variable?
>>
>> Not really, except for the modalias stuff. Use that if you can.
>>
>> But I think you've pointed out the real solution already. You need to
>> look at the signature on the device and then know what to load, just
>> like we do for filesystems.
> It seems to work just fine.
> mtdchar I see it loaded automatically anyway due to char device alias.
What triggers char device aliases? You mean a static /dev with device
nodes without a current kernel device?
> So this rules does the trick:
>
> ACTION!="add", GOTO="mtd_probe_end"
> KERNEL="mtd*ro", IMPORT{program}="mtd_probe --export $tempnode"
> LABEL="mtd_probe_end"
>
> And all I have to do is to write the mtd_probe
>
> My current stub mtd-probe is:
>
> #!/bin/sh
> # $1 = device node
> echo "MODALIAS=sm_ftl"
Modaliases are not supposed to be defined by imported variables. They
are specified by the kernel, and should also be visible in sysfs, if
they are used.
Also modaliases have prefixes like: <subsystem>:<some id>, and should
never be plain module names, to allow module-init-tools to overwrite
things in a sane way. You might want to add MODULE_ALIAS("mtd:sm_ftl")
to the module itself, or whatever fits.
What will the module do when it's loaded? Scan all mtd devices and
check if there is something it should bind to?
Kay
^ permalink raw reply
* Re: New rule for xD FTL driver
From: Maxim Levitsky @ 2010-06-15 19:29 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <1276347244.4481.15.camel@maxim-laptop>
On Tue, 2010-06-15 at 21:02 +0200, Kay Sievers wrote:
> On Tue, Jun 15, 2010 at 19:46, Maxim Levitsky <maximlevitsky@gmail.com> wrote:
> > On Tue, 2010-06-15 at 09:05 -0700, Greg KH wrote:
> >> On Tue, Jun 15, 2010 at 06:45:48PM +0300, Maxim Levitsky wrote:
> >> > Can udev helper tell udev to load modules by setting some variable?
> >>
> >> Not really, except for the modalias stuff. Use that if you can.
> >>
> >> But I think you've pointed out the real solution already. You need to
> >> look at the signature on the device and then know what to load, just
> >> like we do for filesystems.
>
> > It seems to work just fine.
> > mtdchar I see it loaded automatically anyway due to char device alias.
>
> What triggers char device aliases? You mean a static /dev with device
> nodes without a current kernel device?
>
> > So this rules does the trick:
> >
> > ACTION!="add", GOTO="mtd_probe_end"
> > KERNEL="mtd*ro", IMPORT{program}="mtd_probe --export $tempnode"
> > LABEL="mtd_probe_end"
> >
> > And all I have to do is to write the mtd_probe
> >
> > My current stub mtd-probe is:
> >
> > #!/bin/sh
> > # $1 = device node
> > echo "MODALIAS=sm_ftl"
>
> Modaliases are not supposed to be defined by imported variables. They
> are specified by the kernel, and should also be visible in sysfs, if
> they are used.
>
> Also modaliases have prefixes like: <subsystem>:<some id>, and should
> never be plain module names, to allow module-init-tools to overwrite
> things in a sane way. You might want to add MODULE_ALIAS("mtd:sm_ftl")
> to the module itself, or whatever fits.
But what will I do with this?
Let me explain again:
I have low level driver that exposes mtd interface.
And I have high level driver (sm_ftl) that using already existing code
scans for new mtd devices, and binds to these that have 'magic'
signature in first non-bad block.
The low level driver is loaded by PCI core.
The high level driver isn't loaded by anyone.
So I had following options:
1. always load the sm_ftl as soon as mtd device appears. This wasn't
accepted, and I more or less agree on that.
2. As soon as mtd device appeared, spawn userspace helper that will look
for 'magic' signature on its own, and then load the sm_ftl (or other
FTLs).
I partially implemented (2) by binding an udev rule to mtdchar device
creating, which will be opened by my mtd_probe, and scanned for
signature. If signature matches, I will export 'MODALIAS=<ftl driver>'
If you want I can add MODULE_ALIAS("mtd:sm_ftl") to sm_ftl.ko, but I
still need the userspace helper to export
MODALIAS=mtd:sm_ftl
How else can userspace helper tell udev to load a module?
(Sure I can spawn modprobe from it, or do something like that?
ACTION!="add", GOTO="mtd_probe_end"
KERNEL="mtd*ro", IMPORT{program}="mtd_probe --export $tempnode"
KERNEL="mtd*ro", ENV{MTD_MODULE}="?*", RUN+="modprobe $MTD_MODULE"
LABEL="mtd_probe_end"
mtd_probe.sh (placeholder, will be replaced with 'C' program)
#!/bin/sh
# $1 = device node
# now we open and read the mtd mode
if [ $FOUND_SM_FTL_MAGIC = 1 ] ; then
echo "MTD_MODULE=sm_ftl"
fi
But why?
Best regards,
Maxim Levitsky
^ permalink raw reply
* Re: Questions on udev-acl rules, ACL_MANAGE + bug report
From: Julien BLACHE @ 2010-06-16 4:49 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <87k4q82l9k.fsf@sonic.technologeek.org>
Kay Sievers <kay.sievers@vrfy.org> wrote:
Hi,
[udev-acl]
> There is no real long-term plan to explain. It's just that stuff is
> moving all the time. There might be upcoming changes in ConsoleKit
> which require changes again. I'm not really involved in this, don't
It's a bit puzzling to read that, to be honest. "We're going to break
things, deal with it" is becoming a bit old.
> know the details, but I know people talking about new stuff.
Could the above "people" please shed some light on this?
>> Instead of duplicating the rules from libsane, I propose to also set
>> libsane_matched for SCSI scanners starting with the next SANE release
>> (whenever that happens, and I'd encourage distributors to patch the SANE
>> rules right now already).
>>
>> Would that be OK with you?
>
> Sure, sounds good to me. Just let us know, when this is generally
> available in a released version, and we can remove the rule from udev.
I'll do. In the meantime, distributors should patch this up themselves,
as we're probably months away from the next SANE release.
JB.
--
Julien BLACHE <jblache@debian.org> | Debian, because code matters more
Debian & GNU/Linux Developer | <http://www.debian.org>
Public key available on <http://www.jblache.org> - KeyID: F5D6 5169
GPG Fingerprint : 935A 79F1 C8B3 3521 FD62 7CC7 CD61 4FD7 F5D6 5169
^ permalink raw reply
* Re: Questions on udev-acl rules, ACL_MANAGE + bug report
From: Kay Sievers @ 2010-06-16 7:04 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <87k4q82l9k.fsf@sonic.technologeek.org>
On Wed, Jun 16, 2010 at 06:49, Julien BLACHE <jblache@debian.org> wrote:
> Kay Sievers <kay.sievers@vrfy.org> wrote:
>> There is no real long-term plan to explain. It's just that stuff is
>> moving all the time. There might be upcoming changes in ConsoleKit
>> which require changes again. I'm not really involved in this, don't
>
> It's a bit puzzling to read that, to be honest. "We're going to break
> things, deal with it" is becoming a bit old.
I think it's pretty clear: Don't use udev's low-level stuff managing
ACLs directly in packages. There is nothing else that breaks.
This is all very new stuff, and new stuff changes until the pain to
change is larger than the gain of the change. That point is surely not
reached today.
It's not different from any other new stuff that has a certain grade
of complexity -- just don't use it if you can't cope with possible
changes -- because they will very likely happen.
>> know the details, but I know people talking about new stuff.
>
> Could the above "people" please shed some light on this?
You can ask them. It's the people who work on the multi-seat stuff.
But I doubt they can outline a plan more detailed than: don't use the
udev low-level stuff directly in packages. :)
Thanks,
Kay
^ permalink raw reply
* Re: New rule for xD FTL driver
From: Maxim Levitsky @ 2010-06-17 9:38 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <1276347244.4481.15.camel@maxim-laptop>
On Tue, 2010-06-15 at 22:29 +0300, Maxim Levitsky wrote:
> On Tue, 2010-06-15 at 21:02 +0200, Kay Sievers wrote:
> > On Tue, Jun 15, 2010 at 19:46, Maxim Levitsky <maximlevitsky@gmail.com> wrote:
> > > On Tue, 2010-06-15 at 09:05 -0700, Greg KH wrote:
> > >> On Tue, Jun 15, 2010 at 06:45:48PM +0300, Maxim Levitsky wrote:
> > >> > Can udev helper tell udev to load modules by setting some variable?
> > >>
> > >> Not really, except for the modalias stuff. Use that if you can.
> > >>
> > >> But I think you've pointed out the real solution already. You need to
> > >> look at the signature on the device and then know what to load, just
> > >> like we do for filesystems.
> >
> > > It seems to work just fine.
> > > mtdchar I see it loaded automatically anyway due to char device alias.
> >
> > What triggers char device aliases? You mean a static /dev with device
> > nodes without a current kernel device?
> >
> > > So this rules does the trick:
> > >
> > > ACTION!="add", GOTO="mtd_probe_end"
> > > KERNEL="mtd*ro", IMPORT{program}="mtd_probe --export $tempnode"
> > > LABEL="mtd_probe_end"
> > >
> > > And all I have to do is to write the mtd_probe
> > >
> > > My current stub mtd-probe is:
> > >
> > > #!/bin/sh
> > > # $1 = device node
> > > echo "MODALIAS=sm_ftl"
> >
> > Modaliases are not supposed to be defined by imported variables. They
> > are specified by the kernel, and should also be visible in sysfs, if
> > they are used.
> >
> > Also modaliases have prefixes like: <subsystem>:<some id>, and should
> > never be plain module names, to allow module-init-tools to overwrite
> > things in a sane way. You might want to add MODULE_ALIAS("mtd:sm_ftl")
> > to the module itself, or whatever fits.
> But what will I do with this?
>
>
>
> Let me explain again:
> I have low level driver that exposes mtd interface.
> And I have high level driver (sm_ftl) that using already existing code
> scans for new mtd devices, and binds to these that have 'magic'
> signature in first non-bad block.
>
> The low level driver is loaded by PCI core.
> The high level driver isn't loaded by anyone.
>
>
> So I had following options:
>
> 1. always load the sm_ftl as soon as mtd device appears. This wasn't
> accepted, and I more or less agree on that.
>
> 2. As soon as mtd device appeared, spawn userspace helper that will look
> for 'magic' signature on its own, and then load the sm_ftl (or other
> FTLs).
>
>
> I partially implemented (2) by binding an udev rule to mtdchar device
> creating, which will be opened by my mtd_probe, and scanned for
> signature. If signature matches, I will export 'MODALIAS=<ftl driver>'
>
> If you want I can add MODULE_ALIAS("mtd:sm_ftl") to sm_ftl.ko, but I
> still need the userspace helper to export
>
> MODALIAS=mtd:sm_ftl
>
> How else can userspace helper tell udev to load a module?
> (Sure I can spawn modprobe from it, or do something like that?
>
> ACTION!="add", GOTO="mtd_probe_end"
>
> KERNEL="mtd*ro", IMPORT{program}="mtd_probe --export $tempnode"
> KERNEL="mtd*ro", ENV{MTD_MODULE}="?*", RUN+="modprobe $MTD_MODULE"
>
> LABEL="mtd_probe_end"
>
>
> mtd_probe.sh (placeholder, will be replaced with 'C' program)
>
> #!/bin/sh
> # $1 = device node
>
> # now we open and read the mtd mode
>
> if [ $FOUND_SM_FTL_MAGIC = 1 ] ; then
> echo "MTD_MODULE=sm_ftl"
> fi
>
>
>
> But why?
>
>
> Best regards,
> Maxim Levitsky
>
Any update?
Best regards,
Maxim Levitsky
^ permalink raw reply
* [PATCH] Add autodetection for xD cards
From: Maxim Levitsky @ 2010-06-18 0:19 UTC (permalink / raw)
To: linux-hotplug
Hi,
This is the patch implementing the detection in clean way.
Note that I call it smartmedia because xD is direct succesor of
smartmedia and other that different card package is equivalent to it.
---
commit 2599cabd36770785a13bf884049d649d385fd80c
Author: Maxim Levitsky <maximlevitsky@gmail.com>
Date: Fri Jun 18 02:08:48 2010 +0300
Add autodetection for xD/smartmedia cards
This can easily be extended for other types of FTL
Signed-off-by: Maxim Levitsky <maximlevitsky@gmail.com>
diff --git a/Makefile.am b/Makefile.am
index bafe4c7..5e9234a 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -467,6 +467,21 @@ dist_udevrules_DATA += \
libexec_PROGRAMS += extras/mobile-action-modeswitch/mobile-action-modeswitch
# ------------------------------------------------------------------------------
+# mtd_probe - autoloads FTL module for mtd devices
+# ------------------------------------------------------------------------------
+extras_mtd_probe_mtd_probe_SOURCES = \
+ extras/mtd_probe/mtd_probe.c \
+ extras/mtd_probe/mtd_probe.h \
+ extras/mtd_probe/probe_smartmedia.c
+
+extras_mtd_probe_mtd_probe_CPPFLAGS = $(AM_CPPFLAGS)
+
+dist_udevrules_DATA += extras/mtd_probe/75-probe_mtd.rules
+
+libexec_PROGRAMS += extras/mtd_probe/mtd_probe
+
+
+# ------------------------------------------------------------------------------
# keymap - map custom hardware's multimedia keys
# ------------------------------------------------------------------------------
extras_keymap_keymap_SOURCES = extras/keymap/keymap.c
diff --git a/extras/mtd_probe/75-probe_mtd.rules b/extras/mtd_probe/75-probe_mtd.rules
new file mode 100644
index 0000000..1d1b398
--- /dev/null
+++ b/extras/mtd_probe/75-probe_mtd.rules
@@ -0,0 +1,10 @@
+#probe mtd devices for FTL
+
+ACTION!="add", GOTO="mtd_probe_end"
+
+KERNEL="mtd*ro", IMPORT{program}="mtd_probe $tempnode"
+KERNEL="mtd*ro", ENV{MTD_FTL}="smartmedia", RUN+="/sbin/modprobe sm_ftl"
+
+
+LABEL="mtd_probe_end"
+
diff --git a/extras/mtd_probe/mtd_probe.c b/extras/mtd_probe/mtd_probe.c
new file mode 100644
index 0000000..d335b06
--- /dev/null
+++ b/extras/mtd_probe/mtd_probe.c
@@ -0,0 +1,54 @@
+/*
+ * mtd_probe.c
+ * This file is part of mtd_probe
+ *
+ * Copyright (C) 2010 - Maxim Levitsky
+ *
+ * mtd_probe is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * mtd_probe is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with mtd_probe; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin St, Fifth Floor,
+ * Boston, MA 02110-1301 USA
+ */
+#include "mtd_probe.h"
+#include <stdio.h>
+#include <sys/ioctl.h>
+#include <mtd/mtd-user.h>
+#include <sys/types.h>
+#include <sys/stat.h>
+#include <fcntl.h>
+#include <unistd.h>
+#include <stdlib.h>
+
+int main(int argc, char** argv) {
+
+ if (argc != 2) {
+ printf("usage: mtd_probe /dev/mtd[n]\n");
+ return 1;
+ }
+
+ int mtd_fd = open(argv[1], O_RDONLY);
+ if (mtd_fd = -1) {
+ perror("open");
+ exit(-1);
+ }
+
+ mtd_info_t mtd_info;
+ int error = ioctl(mtd_fd, MEMGETINFO, &mtd_info);
+ if (error = -1) {
+ perror("ioctl");
+ exit(-1);
+ }
+
+ probe_smart_media(mtd_fd, &mtd_info);
+ return -1;
+}
diff --git a/extras/mtd_probe/mtd_probe.h b/extras/mtd_probe/mtd_probe.h
new file mode 100644
index 0000000..845a7a1
--- /dev/null
+++ b/extras/mtd_probe/mtd_probe.h
@@ -0,0 +1,51 @@
+/*
+ * mtd_probe.h
+ * This file is part of mtd_probe
+ *
+ * Copyright (C) 2010 - Maxim Levitsky
+ *
+ * mtd_probe is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * mtd_probe is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with mtd_probe; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin St, Fifth Floor,
+ * Boston, MA 02110-1301 USA
+ */
+#include <mtd/mtd-user.h>
+
+/* Full oob structure as written on the flash */
+struct sm_oob {
+ uint32_t reserved;
+ uint8_t data_status;
+ uint8_t block_status;
+ uint8_t lba_copy1[2];
+ uint8_t ecc2[3];
+ uint8_t lba_copy2[2];
+ uint8_t ecc1[3];
+} __attribute__((packed));
+
+
+/* one sector is always 512 bytes, but it can consist of two nand pages */
+#define SM_SECTOR_SIZE 512
+
+/* oob area is also 16 bytes, but might be from two pages */
+#define SM_OOB_SIZE 16
+
+/* This is maximum zone size, and all devices that have more that one zone
+ have this size */
+#define SM_MAX_ZONE_SIZE 1024
+
+/* support for small page nand */
+#define SM_SMALL_PAGE 256
+#define SM_SMALL_OOB_SIZE 8
+
+
+void probe_smart_media(int mtd_fd, mtd_info_t *info);
diff --git a/extras/mtd_probe/probe_smartmedia.c b/extras/mtd_probe/probe_smartmedia.c
new file mode 100644
index 0000000..ab6edea
--- /dev/null
+++ b/extras/mtd_probe/probe_smartmedia.c
@@ -0,0 +1,99 @@
+/*
+ * probe_smartmedia.c
+ * This file is part of mtd_probe
+ *
+ * Copyright (C) 2010 - Maxim Levitsky
+ *
+ * mtd_probe is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * mtd_probe is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with mtd_probe; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin St, Fifth Floor,
+ * Boston, MA 02110-1301 USA
+ */
+
+#include <stdio.h>
+#include <stdlib.h>
+#include <mtd/mtd-user.h>
+
+#include <sys/types.h>
+#include <sys/stat.h>
+#include <fcntl.h>
+#include <unistd.h>
+#include <stdint.h>
+#include <stdlib.h>
+#include "mtd_probe.h"
+
+static const uint8_t cis_signature[] = {
+ 0x01, 0x03, 0xD9, 0x01, 0xFF, 0x18, 0x02, 0xDF, 0x01, 0x20
+};
+
+
+void probe_smart_media(int mtd_fd, mtd_info_t* info) {
+
+ char* cis_buffer = malloc(SM_SECTOR_SIZE);
+ if (!cis_buffer)
+ return;
+
+ if (info->type != MTD_NANDFLASH)
+ goto exit;
+
+ int sector_size = info->writesize;
+ int block_size = info->erasesize;
+ int size_in_megs = info->size / (1024 * 1024);
+ int spare_count;
+
+
+ if (sector_size != SM_SECTOR_SIZE && sector_size != SM_SMALL_PAGE)
+ goto exit;
+
+ switch(size_in_megs) {
+ case 1:
+ case 2:
+ spare_count = 6;
+ break;
+ case 4:
+ spare_count = 12;
+ break;
+ default:
+ spare_count = 24;
+ break;
+ }
+
+
+ int offset;
+ int cis_found = 0;
+
+ for (offset = 0 ; offset < block_size * spare_count ;
+ offset += sector_size) {
+
+ lseek(mtd_fd, SEEK_SET, offset);
+ if (read(mtd_fd, cis_buffer, SM_SECTOR_SIZE) = SM_SECTOR_SIZE){
+ cis_found = 1;
+ break;
+ }
+ }
+
+ if (!cis_found)
+ goto exit;
+
+ if (memcmp(cis_buffer, cis_signature, sizeof(cis_signature)) != 0 &&
+ (memcmp(cis_buffer + SM_SMALL_PAGE, cis_signature,
+ sizeof(cis_signature)) != 0))
+ goto exit;
+
+ printf("MTD_FTL=smartmedia\n");
+ free(cis_buffer);
+ exit(0);
+exit:
+ free(cis_buffer);
+ return;
+}
^ permalink raw reply related
* Weird race-like problem in udev
From: Ozan Çağlayan @ 2010-06-21 16:47 UTC (permalink / raw)
To: linux-hotplug
Hi,
I have a bug report from a user which complains about udev not correctly hotplugging the devices. The symptoms are quite racy and random:
* When he starts the OS and plugs a USB device, udev doesn't load the necessary kernel driver,
* He then unplugs/plugs it several times:
* Sometimes it starts to work correctly, the module gets inserted
* Sometimes it still doesn't modprobe the module
* He discovered that spawning a 2nd udevd by hand resolves the issue
I suggested him to set the udevd log level to "debug" and we've found out that setting the log level through udevadm control heals the issue as well. So I proposed to edit the udev.conf and set the log level there and reboot. Upon reboot, after a cycle of 2-3 failed plug/unplug attempt, the problem seems fixed/disappeared too.
I grabbed full syslog with udevd running log-priorityfibug, took a look and found out that the events are correctly dispatched to the worker threads but the modprobe is called on a very late plug/unplug attempt.
Here's the full log:
http://bugs.pardus.org.tr/attachment.cgi?idT50
* The device is first plugged @ 16:50:54 (VENDOR=_USB_MF_)
* worker[541] being able to spawn modprobe is @ 16:53:21
* Between those timestamps you can see several "seq xxxx queued 'add' 'usb' which doesn't lead to a modprobe.
udev version is 146. I know that it's a little bit outdated but I'd be glad if you can help me debugging the issue. Any commit id from the git tree that is known to fix the issue is also very appreciated.
Thanks,
Ozan Caglayan
--
http://www.pardus.org.tr/eng
--
To unsubscribe from this list: send the line "unsubscribe linux-hotplug" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH] Add autodetection for xD cards
From: Maxim Levitsky @ 2010-06-21 19:21 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <1276820353.2762.4.camel@maxim-laptop>
On Fri, 2010-06-18 at 03:19 +0300, Maxim Levitsky wrote:
> Hi,
> This is the patch implementing the detection in clean way.
> Note that I call it smartmedia because xD is direct succesor of
> smartmedia and other that different card package is equivalent to it.
>
ping
> ---
>
>
> commit 2599cabd36770785a13bf884049d649d385fd80c
> Author: Maxim Levitsky <maximlevitsky@gmail.com>
> Date: Fri Jun 18 02:08:48 2010 +0300
>
> Add autodetection for xD/smartmedia cards
> This can easily be extended for other types of FTL
> Signed-off-by: Maxim Levitsky <maximlevitsky@gmail.com>
>
> diff --git a/Makefile.am b/Makefile.am
> index bafe4c7..5e9234a 100644
> --- a/Makefile.am
> +++ b/Makefile.am
> @@ -467,6 +467,21 @@ dist_udevrules_DATA += \
> libexec_PROGRAMS += extras/mobile-action-modeswitch/mobile-action-modeswitch
>
> # ------------------------------------------------------------------------------
> +# mtd_probe - autoloads FTL module for mtd devices
> +# ------------------------------------------------------------------------------
> +extras_mtd_probe_mtd_probe_SOURCES = \
> + extras/mtd_probe/mtd_probe.c \
> + extras/mtd_probe/mtd_probe.h \
> + extras/mtd_probe/probe_smartmedia.c
> +
> +extras_mtd_probe_mtd_probe_CPPFLAGS = $(AM_CPPFLAGS)
> +
> +dist_udevrules_DATA += extras/mtd_probe/75-probe_mtd.rules
> +
> +libexec_PROGRAMS += extras/mtd_probe/mtd_probe
> +
> +
> +# ------------------------------------------------------------------------------
> # keymap - map custom hardware's multimedia keys
> # ------------------------------------------------------------------------------
> extras_keymap_keymap_SOURCES = extras/keymap/keymap.c
> diff --git a/extras/mtd_probe/75-probe_mtd.rules b/extras/mtd_probe/75-probe_mtd.rules
> new file mode 100644
> index 0000000..1d1b398
> --- /dev/null
> +++ b/extras/mtd_probe/75-probe_mtd.rules
> @@ -0,0 +1,10 @@
> +#probe mtd devices for FTL
> +
> +ACTION!="add", GOTO="mtd_probe_end"
> +
> +KERNEL="mtd*ro", IMPORT{program}="mtd_probe $tempnode"
> +KERNEL="mtd*ro", ENV{MTD_FTL}="smartmedia", RUN+="/sbin/modprobe sm_ftl"
> +
> +
> +LABEL="mtd_probe_end"
> +
> diff --git a/extras/mtd_probe/mtd_probe.c b/extras/mtd_probe/mtd_probe.c
> new file mode 100644
> index 0000000..d335b06
> --- /dev/null
> +++ b/extras/mtd_probe/mtd_probe.c
> @@ -0,0 +1,54 @@
> +/*
> + * mtd_probe.c
> + * This file is part of mtd_probe
> + *
> + * Copyright (C) 2010 - Maxim Levitsky
> + *
> + * mtd_probe is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by
> + * the Free Software Foundation; either version 2 of the License, or
> + * (at your option) any later version.
> + *
> + * mtd_probe is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> + * GNU General Public License for more details.
> + *
> + * You should have received a copy of the GNU General Public License
> + * along with mtd_probe; if not, write to the Free Software
> + * Foundation, Inc., 51 Franklin St, Fifth Floor,
> + * Boston, MA 02110-1301 USA
> + */
> +#include "mtd_probe.h"
> +#include <stdio.h>
> +#include <sys/ioctl.h>
> +#include <mtd/mtd-user.h>
> +#include <sys/types.h>
> +#include <sys/stat.h>
> +#include <fcntl.h>
> +#include <unistd.h>
> +#include <stdlib.h>
> +
> +int main(int argc, char** argv) {
> +
> + if (argc != 2) {
> + printf("usage: mtd_probe /dev/mtd[n]\n");
> + return 1;
> + }
> +
> + int mtd_fd = open(argv[1], O_RDONLY);
> + if (mtd_fd = -1) {
> + perror("open");
> + exit(-1);
> + }
> +
> + mtd_info_t mtd_info;
> + int error = ioctl(mtd_fd, MEMGETINFO, &mtd_info);
> + if (error = -1) {
> + perror("ioctl");
> + exit(-1);
> + }
> +
> + probe_smart_media(mtd_fd, &mtd_info);
> + return -1;
> +}
> diff --git a/extras/mtd_probe/mtd_probe.h b/extras/mtd_probe/mtd_probe.h
> new file mode 100644
> index 0000000..845a7a1
> --- /dev/null
> +++ b/extras/mtd_probe/mtd_probe.h
> @@ -0,0 +1,51 @@
> +/*
> + * mtd_probe.h
> + * This file is part of mtd_probe
> + *
> + * Copyright (C) 2010 - Maxim Levitsky
> + *
> + * mtd_probe is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by
> + * the Free Software Foundation; either version 2 of the License, or
> + * (at your option) any later version.
> + *
> + * mtd_probe is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> + * GNU General Public License for more details.
> + *
> + * You should have received a copy of the GNU General Public License
> + * along with mtd_probe; if not, write to the Free Software
> + * Foundation, Inc., 51 Franklin St, Fifth Floor,
> + * Boston, MA 02110-1301 USA
> + */
> +#include <mtd/mtd-user.h>
> +
> +/* Full oob structure as written on the flash */
> +struct sm_oob {
> + uint32_t reserved;
> + uint8_t data_status;
> + uint8_t block_status;
> + uint8_t lba_copy1[2];
> + uint8_t ecc2[3];
> + uint8_t lba_copy2[2];
> + uint8_t ecc1[3];
> +} __attribute__((packed));
> +
> +
> +/* one sector is always 512 bytes, but it can consist of two nand pages */
> +#define SM_SECTOR_SIZE 512
> +
> +/* oob area is also 16 bytes, but might be from two pages */
> +#define SM_OOB_SIZE 16
> +
> +/* This is maximum zone size, and all devices that have more that one zone
> + have this size */
> +#define SM_MAX_ZONE_SIZE 1024
> +
> +/* support for small page nand */
> +#define SM_SMALL_PAGE 256
> +#define SM_SMALL_OOB_SIZE 8
> +
> +
> +void probe_smart_media(int mtd_fd, mtd_info_t *info);
> diff --git a/extras/mtd_probe/probe_smartmedia.c b/extras/mtd_probe/probe_smartmedia.c
> new file mode 100644
> index 0000000..ab6edea
> --- /dev/null
> +++ b/extras/mtd_probe/probe_smartmedia.c
> @@ -0,0 +1,99 @@
> +/*
> + * probe_smartmedia.c
> + * This file is part of mtd_probe
> + *
> + * Copyright (C) 2010 - Maxim Levitsky
> + *
> + * mtd_probe is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by
> + * the Free Software Foundation; either version 2 of the License, or
> + * (at your option) any later version.
> + *
> + * mtd_probe is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> + * GNU General Public License for more details.
> + *
> + * You should have received a copy of the GNU General Public License
> + * along with mtd_probe; if not, write to the Free Software
> + * Foundation, Inc., 51 Franklin St, Fifth Floor,
> + * Boston, MA 02110-1301 USA
> + */
> +
> +#include <stdio.h>
> +#include <stdlib.h>
> +#include <mtd/mtd-user.h>
> +
> +#include <sys/types.h>
> +#include <sys/stat.h>
> +#include <fcntl.h>
> +#include <unistd.h>
> +#include <stdint.h>
> +#include <stdlib.h>
> +#include "mtd_probe.h"
> +
> +static const uint8_t cis_signature[] = {
> + 0x01, 0x03, 0xD9, 0x01, 0xFF, 0x18, 0x02, 0xDF, 0x01, 0x20
> +};
> +
> +
> +void probe_smart_media(int mtd_fd, mtd_info_t* info) {
> +
> + char* cis_buffer = malloc(SM_SECTOR_SIZE);
> + if (!cis_buffer)
> + return;
> +
> + if (info->type != MTD_NANDFLASH)
> + goto exit;
> +
> + int sector_size = info->writesize;
> + int block_size = info->erasesize;
> + int size_in_megs = info->size / (1024 * 1024);
> + int spare_count;
> +
> +
> + if (sector_size != SM_SECTOR_SIZE && sector_size != SM_SMALL_PAGE)
> + goto exit;
> +
> + switch(size_in_megs) {
> + case 1:
> + case 2:
> + spare_count = 6;
> + break;
> + case 4:
> + spare_count = 12;
> + break;
> + default:
> + spare_count = 24;
> + break;
> + }
> +
> +
> + int offset;
> + int cis_found = 0;
> +
> + for (offset = 0 ; offset < block_size * spare_count ;
> + offset += sector_size) {
> +
> + lseek(mtd_fd, SEEK_SET, offset);
> + if (read(mtd_fd, cis_buffer, SM_SECTOR_SIZE) = SM_SECTOR_SIZE){
> + cis_found = 1;
> + break;
> + }
> + }
> +
> + if (!cis_found)
> + goto exit;
> +
> + if (memcmp(cis_buffer, cis_signature, sizeof(cis_signature)) != 0 &&
> + (memcmp(cis_buffer + SM_SMALL_PAGE, cis_signature,
> + sizeof(cis_signature)) != 0))
> + goto exit;
> +
> + printf("MTD_FTL=smartmedia\n");
> + free(cis_buffer);
> + exit(0);
> +exit:
> + free(cis_buffer);
> + return;
> +}
>
>
^ permalink raw reply
* Re: Weird race-like problem in udev
From: Kay Sievers @ 2010-06-22 11:31 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <4C1F97A0.2040905@pardus.org.tr>
On Mon, Jun 21, 2010 at 18:47, Ozan Çağlayan <ozan@pardus.org.tr> wrote:
> I have a bug report from a user which complains about udev not correctly hotplugging the devices. The symptoms are quite racy and random:
>
> * When he starts the OS and plugs a USB device, udev doesn't load the necessary kernel driver,
Please, this isn't a quiz here, so provide the needed basic
information that goes beyond "a device" and " the driver". :)
> * He then unplugs/plugs it several times:
> * Sometimes it starts to work correctly, the module gets inserted
> * Sometimes it still doesn't modprobe the module
Check 'udevadm monitor' for the difference of both cases.
> * He discovered that spawning a 2nd udevd by hand resolves the issue
That's not possible, udevd will refuse to start a second time, and not
do anything. It lets this report look suspicious that something is
wrong with the way the behavior is described.
Kay
^ permalink raw reply
* Re: Weird race-like problem in udev
From: Ozan Çağlayan @ 2010-06-22 12:06 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <4C1F97A0.2040905@pardus.org.tr>
Salı 22 Haziran 2010 günü (saat 14:31:57) Kay Sievers şunları yazmıştı:
>
> Please, this isn't a quiz here, so provide the needed basic
> information that goes beyond "a device" and " the driver". :)
Ok, I'm very suspicious about the report and what the user describes, too.
I'll try to detail in here.
What he's talking about in its bug report is a USB mass storage device:
[ 4741.302054] usb 1-2: new high speed USB device using ehci_hcd and address 3
[ 4743.914330] usb 1-2: New USB device found, idVendor\x066f, idProduct€00
[ 4743.914343] usb 1-2: New USB device strings: Mfr=1, Product=2,
SerialNumber=3
[ 4743.914353] usb 1-2: Product: <USB PRODUCT>
[ 4743.914360] usb 1-2: Manufacturer: <USB MF>
[ 4743.914367] usb 1-2: SerialNumber: 0002F68C0A104E19
[ 4743.914623] usb 1-2: configuration #1 chosen from 1 choice
He also mentions that its webcam driver doesn't get loaded too. He posted the
test-webcam output which complains about a non existing /dev/video0 node.
If the devices are plugged and then the system is rebooted, all the related
drivers are loaded and he tells that he has no problems at all.
>
> > * He discovered that spawning a 2nd udevd by hand resolves the issue
>
> That's not possible, udevd will refuse to start a second time, and not
> do anything. It lets this report look suspicious that something is
> wrong with the way the behavior is described.
I misunderstood this. He was talking about killing and respawning udevd, not
spawning a 2nd or a 3rd one, sorry. But yes he says that killing and
respawning it resolves the issue.
I am not really hopeful to get this resolved as trying to ask him and waiting
for an answer is very hard for that kind of standard users who are not
familiar at all with udev, kernel, etc. Sorry for the inconvenience, I will
report back here if I get something valuable.
Regards,
---
Ozan Çağlayan
TUBITAK/UEKAE - Pardus Linux
http://www.pardus.org.tr/eng
^ permalink raw reply
* Re: Weird race-like problem in udev
From: Kay Sievers @ 2010-06-22 13:40 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <4C1F97A0.2040905@pardus.org.tr>
On Tue, Jun 22, 2010 at 14:06, Ozan Çağlayan <ozan@pardus.org.tr> wrote:
> Salı 22 Haziran 2010 günü (saat 14:31:57) Kay Sievers şunları yazmıştı:
>> > * He discovered that spawning a 2nd udevd by hand resolves the issue
>>
>> That's not possible, udevd will refuse to start a second time, and not
>> do anything. It lets this report look suspicious that something is
>> wrong with the way the behavior is described.
>
> I misunderstood this. He was talking about killing and respawning udevd, not
> spawning a 2nd or a 3rd one, sorry. But yes he says that killing and
> respawning it resolves the issue.
Hmm, restarting udevd does not cause a single event to run. Only
unplugging/re-plugging would do that, but I doubt that this makes a
difference with the originally started daemon.
Kay
^ permalink raw reply
* [ANNOUNCE] udev 158 release
From: Kay Sievers @ 2010-06-24 8:28 UTC (permalink / raw)
To: linux-hotplug
Here comes a new udev version. Thanks to all who have contributed to
this release.
The tarball can be found here:
ftp://ftp.kernel.org/pub/linux/utils/kernel/hotplug/
The development repository can be found here:
http://www.kernel.org/git/?p=linux/hotplug/udev.git;a=summary
The ChangeLog can be found here:
http://www.kernel.org/git/?p=linux/hotplug/udev.git;a=blob;hb=HEAD;f=ChangeLog
udev 158
====
Bugfixes.
All distribution specific rules are removed from the udev source tree,
most of them are no longer needed. The Gentoo rules which allow to support
older kernel versions, which are not covered by the default rules anymore,
have moved to rules/misc/30-kernel-compat.rules.
^ permalink raw reply
* udevadm Operations Resulting in Unmounted /proc and /sys?
From: Scott Talbert @ 2010-06-25 3:50 UTC (permalink / raw)
To: linux-hotplug
Hello,
I am trying to investigate an issue that occurs during the upgrade of
Ubuntu 9.10 to 10.04 that appears to occur when the root filesystem
resides on a 'removable' device (ie, a flash drive). Things seem to go
wrong when one package's post-install script calls:
udevadm trigger --subsystem-match=block --action=change
After this command is issued, /proc and /sys appear to become unmounted
somehow, and the upgrade fails due to not having /proc mounted.
Does anyone have any advice on how to investigate further why /proc and
/sys are getting unmounted?
Thank you,
Scott Talbert
^ permalink raw reply
* Re: udevadm Operations Resulting in Unmounted /proc and /sys?
From: Kay Sievers @ 2010-06-25 6:05 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <alpine.LRH.2.00.1006242343150.14034@bear.techie.net>
On Fri, Jun 25, 2010 at 05:50, Scott Talbert <talbert@techie.net> wrote:
> I am trying to investigate an issue that occurs during the upgrade of Ubuntu
> 9.10 to 10.04 that appears to occur when the root filesystem resides on a
> 'removable' device (ie, a flash drive). Â Things seem to go wrong when one
> package's post-install script calls:
>
> udevadm trigger --subsystem-match=block --action=change
>
> After this command is issued, /proc and /sys appear to become unmounted
> somehow, and the upgrade fails due to not having /proc mounted.
>
> Does anyone have any advice on how to investigate further why /proc and /sys
> are getting unmounted?
You better ask at an Ubuntu specific list or bugtracker. This is not a
known, or commonly possible behavior, and sound like some distribution
specific thing goes wrong here.
Kay
^ permalink raw reply
* Re: udevadm Operations Resulting in Unmounted /proc and /sys?
From: Martin Pitt @ 2010-06-25 11:24 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <alpine.LRH.2.00.1006242343150.14034@bear.techie.net>
Hello Scott,
Scott Talbert [2010-06-24 23:50 -0400]:
> udevadm trigger --subsystem-match=block --action=change
>
> After this command is issued, /proc and /sys appear to become
> unmounted somehow
Please do "ubuntu-bug mountall" and attach the following information:
* "udevadm monitor -e --udev" output while you manually do above
trigger command
* "mount" output before and after the command
* /etc/fstab (just in case..)
We do not ship any udev patches compared to upstream (just some git
trunk cherrypicks), but udev is not really responsible for
mounting/unmounting in the first place. mountall is a plausible
candidate, but we can always reassign it to the correct package later
on.
Martin
--
Martin Pitt | http://www.piware.de
Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org)
^ permalink raw reply
* [PATCH] path_id: add handle_scsi_sas
From: harald @ 2010-06-25 12:28 UTC (permalink / raw)
To: linux-hotplug
From: Harald Hoyer <harald@redhat.com>
based on code by Jim Garlick.
---
| 64 +++++++++++++++++++++++++++++++++++++++++++++-
1 files changed, 63 insertions(+), 1 deletions(-)
--git a/extras/path_id/path_id.c b/extras/path_id/path_id.c
index dcee378..8dbdd30 100644
--- a/extras/path_id/path_id.c
+++ b/extras/path_id/path_id.c
@@ -121,7 +121,69 @@ out:
static struct udev_device *handle_scsi_sas(struct udev_device *parent, char **path)
{
- return NULL;
+ struct udev *udev = udev_device_get_udev(parent);
+ struct udev_device *end_dev;
+ struct udev_device *sasdev;
+ struct udev_device *phydev;
+ struct udev_device *parent_dev;
+ struct udev_device *child_dev;
+ char syspath[UTIL_PATH_SIZE], *base;
+ char phy_path[UTIL_PATH_SIZE];
+ const char *end_name, *name, *enc, *bay;
+ const char *port_path;
+ int scsi_host;
+ int num_phys = 8;
+ int i;
+
+ parent_dev = parent;
+ while (1) {
+ child_dev = parent_dev;
+ parent_dev = udev_device_get_parent(child_dev);
+ if (parent_dev = NULL)
+ return NULL;
+ name = udev_device_get_sysname(parent_dev);
+ if (strstr(name, "end_device-")) {
+ end_dev = parent_dev;
+ end_name = name;
+ } else if (sscanf(name, "host%d", &scsi_host)) {
+ port_path = udev_device_get_syspath(child_dev);
+ break;
+ }
+ }
+
+ base = strdup(udev_device_get_syspath(end_dev));
+ if (!base)
+ return NULL;
+ snprintf(syspath, sizeof(syspath), "%s/sas_device/%s", base, end_name);
+ free(base);
+
+ for (i = 0 ; i < num_phys ; i++) {
+ snprintf(phy_path, sizeof(phy_path), "%s/phy-%d:%d",
+ port_path, scsi_host, i);
+ if (phydev = udev_device_new_from_syspath(udev, phy_path)) {
+ udev_device_unref(phydev);
+ break;
+ }
+ }
+ if (i = num_phys)
+ return NULL;
+
+ sasdev = udev_device_new_from_syspath(udev, syspath);
+ if (sasdev = NULL) {
+ fprintf(stderr, "unable to access '%s'\n", syspath);
+ return NULL;
+ }
+ enc = udev_device_get_sysattr_value(sasdev, "enclosure_identifier");
+ bay = udev_device_get_sysattr_value(sasdev, "bay_identifier");
+ if (bay = NULL) {
+ parent = NULL;
+ goto out;
+ }
+
+ path_prepend(path, "sas-%s-%s-%s", strrchr(phy_path, '/') + 1, enc : "unknown", bay);
+out:
+ udev_device_unref(sasdev);
+ return parent;
}
static struct udev_device *handle_scsi_iscsi(struct udev_device *parent, char **path)
--
1.7.0.1
^ permalink raw reply related
* [PATCH] path_id: add handle_scsi_sas
From: harald @ 2010-06-25 13:27 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <1277468902-12862-1-git-send-email-harald@redhat.com>
From: Harald Hoyer <harald@redhat.com>
based on code by Jim Garlick.
---
| 64 +++++++++++++++++++++++++++++++++++++++++++++-
1 files changed, 63 insertions(+), 1 deletions(-)
--git a/extras/path_id/path_id.c b/extras/path_id/path_id.c
index dcee378..c3d241b 100644
--- a/extras/path_id/path_id.c
+++ b/extras/path_id/path_id.c
@@ -121,7 +121,69 @@ out:
static struct udev_device *handle_scsi_sas(struct udev_device *parent, char **path)
{
- return NULL;
+ struct udev *udev = udev_device_get_udev(parent);
+ struct udev_device *end_dev;
+ struct udev_device *sasdev;
+ struct udev_device *phydev;
+ struct udev_device *parent_dev;
+ struct udev_device *child_dev;
+ char syspath[UTIL_PATH_SIZE], *base;
+ char phy_path[UTIL_PATH_SIZE];
+ const char *end_name, *name, *enc, *bay;
+ const char *port_path;
+ int scsi_host;
+ int num_phys = 8;
+ int i;
+
+ parent_dev = parent;
+ while (1) {
+ child_dev = parent_dev;
+ parent_dev = udev_device_get_parent(child_dev);
+ if (parent_dev = NULL)
+ return NULL;
+ name = udev_device_get_sysname(parent_dev);
+ if (strstr(name, "end_device-")) {
+ end_dev = parent_dev;
+ end_name = name;
+ } else if (sscanf(name, "host%d", &scsi_host)) {
+ port_path = udev_device_get_syspath(child_dev);
+ break;
+ }
+ }
+
+ base = strdup(udev_device_get_syspath(end_dev));
+ if (!base)
+ return NULL;
+ snprintf(syspath, sizeof(syspath), "%s/sas_device/%s", base, end_name);
+ free(base);
+
+ for (i = 0 ; i < num_phys ; i++) {
+ snprintf(phy_path, sizeof(phy_path), "%s/phy-%d:%d",
+ port_path, scsi_host, i);
+ if (phydev = udev_device_new_from_syspath(udev, phy_path)) {
+ udev_device_unref(phydev);
+ break;
+ }
+ }
+ if (i = num_phys)
+ return NULL;
+
+ sasdev = udev_device_new_from_syspath(udev, syspath);
+ if (sasdev = NULL) {
+ fprintf(stderr, "unable to access '%s'\n", syspath);
+ return NULL;
+ }
+ enc = udev_device_get_sysattr_value(sasdev, "enclosure_identifier");
+ bay = udev_device_get_sysattr_value(sasdev, "bay_identifier");
+ if (bay = NULL) {
+ parent = NULL;
+ goto out;
+ }
+
+ path_prepend(path, "sas-%s-%s-%s", strrchr(phy_path, '/') + 1, enc ? enc : "unknown", bay);
+out:
+ udev_device_unref(sasdev);
+ return parent;
}
static struct udev_device *handle_scsi_iscsi(struct udev_device *parent, char **path)
--
1.7.0.1
^ permalink raw reply related
* Re: [PATCH] path_id: add handle_scsi_sas
From: Harald Hoyer @ 2010-06-25 13:29 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <1277468902-12862-1-git-send-email-harald@redhat.com>
On 06/25/2010 02:28 PM, harald@redhat.com wrote:
> + path_prepend(path, "sas-%s-%s-%s", strrchr(phy_path, '/') + 1, enc : "unknown", bay);
copy & paste error here... revised patch follows
^ permalink raw reply
* [PATCH v3 0/2] Add virtio-blk support to persistent-storage rules
From: Ryan Harper @ 2010-06-25 13:59 UTC (permalink / raw)
To: linux-hotplug; +Cc: john cooper, Rusty Russell, qemu-devel, Ryan Harper
This patch series provides updates to udev to allow the creation symlinks for
virtio-blk devices, specifically disk/by-id and disk/by-path. This is most
useful for virtio-blk devices that do not yet have any filesystem for which a
UUID can be extracted (disk/by-uuid). These patches (save the path_id fix)
require an updated[1] qemu (on the host) and virtio-blk (in the guest)[2] to
generate the by-id path; however if the guest or host qemu isn't capable
then no action is taken.
Changes since v2:
- Added 'serial' sysfs attribute to virtio-blk code upstream [2]
- Dropped VBID ioctl upstream [3]
- Switched rules to extract serial attributes directly
Changes since v1:
- Switch ID_VIRTIO_SERIAL to ID_SERIAL
- Switched IOCTL_CMD to use numeric value
- Add ID_SERIAL_SHORT
- Update persistent-storage rules to use ID_SERIAL for virtioblk_id
1. http://lists.gnu.org/archive/html/qemu-devel/2010-03/msg01869.html
2. https://lists.linux-foundation.org/pipermail/virtualization/2010-June/015326.html
3. https://lists.linux-foundation.org/pipermail/virtualization/2010-June/015325.html
^ permalink raw reply
* [PATCH 1/2] Add virtio-blk support to path_id
From: Ryan Harper @ 2010-06-25 13:59 UTC (permalink / raw)
To: linux-hotplug; +Cc: john cooper, Rusty Russell, qemu-devel, Ryan Harper
In-Reply-To: <1277474363-6534-1-git-send-email-ryanh@us.ibm.com>
This patch adds a case handling path_id invoked on a virtio-blk device.
Currently path_id walks the parent path to virtio-pci but doesn't know
that it's the end of the path and exits without building the path (providing no
output resulting in no disk/by-path symlinks to virtio-blk devices).
This patch handles the virtio-pci path and updates the path accordingly.
/lib/udev/path_id --debug /block/vda
udev_device_new_from_syspath: device 0x2300120 has devpath '/devices/virtio-pci/virtio1/block/vda'
udev_device_new_from_syspath: device 0x2300380 has devpath '/devices/virtio-pci/virtio1'
udev_device_new_from_syspath: device 0x2300670 has devpath '/devices/virtio-pci'
ID_PATH=virtio-pci-virtio1
And with the current persistent-storage rules generates:
% ls -al /dev/disk/by-path | grep vda
lrwxrwxrwx. 1 root root 9 Jun 1 22:09 virtio-pci-virtio1 -> ../../vda
Signed-off-by: Ryan Harper <ryanh@us.ibm.com>
---
| 3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
--git a/extras/path_id/path_id.c b/extras/path_id/path_id.c
index dcee378..c19bfd0 100644
--- a/extras/path_id/path_id.c
+++ b/extras/path_id/path_id.c
@@ -448,6 +448,9 @@ int main(int argc, char **argv)
} else if (strcmp(subsys, "xen") = 0) {
path_prepend(&path, "xen-%s", udev_device_get_sysname(parent));
parent = skip_subsystem(parent, "xen");
+ } else if (strcmp(subsys, "virtio") = 0) {
+ path_prepend(&path, "virtio-pci-%s", udev_device_get_sysname(parent));
+ parent = skip_subsystem(parent, "virtio");
}
parent = udev_device_get_parent(parent);
--
1.6.3.3
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox