Re: [PATCH 2.6.24] block2mtd: removing a device and typo fixes
On Wed, 20 February 2008 17:30:53 +, Stephane Chazelas wrote: > > > > Actually, there is /dev/mtd. Enable CONFIG_MTD_CHAR. > > Yes, my point ;). "block2mtd" creates a "mtd" out of a block > device and "mtdchar" and "mtdblock" create the "char" and > "block" devices out of the "mtd". This is a different concept > from "loop". With "loop", you make a block device out of a file, > but you do the ioctl on the target loop block device itself. > With block2mtd, you can't do that. The fact is that there is _no_ interface to manage mtd. Part of the reason is this tradition to have seperate modules every couple of lines of code. In other subsystems, CONFIG_MTD_CHAR would not exist and the code always be compiled in. Simply to get _some_ interface to handle the device that is always there. Without going much deeper into that discussion, I consider it acceptable to depend on CONFIG_MTD_CHAR for things like device removal. If you want device removal and explicitly don't want the extra code from mtdchar.c, send a patch or go find 500 bytes to save elsewhere. ;) With that out of the way, the question remains which interface we should have. Independently of mimicking loop, I would like to have a generic interface for all mtd, not just block2mtd. Whether it is "echo 1 > /sys/.../mtd/mtdN/remove" or an ioctl(), I don't care much about. > Actually, that's what I use block2mtd for, in combination with > "loop" to mount jffs2 filesystem images (always wondered if > there wasn't a simpler way, BTW (other than mtdram)) Logfs can use a block device directly, which still leaves loop. Enhancing block2mtd to work with files shouldn't be too hard. If anyone want a fun project to hack on... Jörn -- Data dominates. If you've chosen the right data structures and organized things well, the algorithms will almost always be self-evident. Data structures, not algorithms, are central to programming. -- Rob Pike -- 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: [PATCH 2.6.24] block2mtd: removing a device and typo fixes
On Wed, 20 February 2008 17:30:53 +, Stephane Chazelas wrote: Actually, there is /dev/mtdx. Enable CONFIG_MTD_CHAR. Yes, my point ;). block2mtd creates a mtd out of a block device and mtdchar and mtdblock create the char and block devices out of the mtd. This is a different concept from loop. With loop, you make a block device out of a file, but you do the ioctl on the target loop block device itself. With block2mtd, you can't do that. The fact is that there is _no_ interface to manage mtd. Part of the reason is this tradition to have seperate modules every couple of lines of code. In other subsystems, CONFIG_MTD_CHAR would not exist and the code always be compiled in. Simply to get _some_ interface to handle the device that is always there. Without going much deeper into that discussion, I consider it acceptable to depend on CONFIG_MTD_CHAR for things like device removal. If you want device removal and explicitly don't want the extra code from mtdchar.c, send a patch or go find 500 bytes to save elsewhere. ;) With that out of the way, the question remains which interface we should have. Independently of mimicking loop, I would like to have a generic interface for all mtd, not just block2mtd. Whether it is echo 1 /sys/.../mtd/mtdN/remove or an ioctl(), I don't care much about. Actually, that's what I use block2mtd for, in combination with loop to mount jffs2 filesystem images (always wondered if there wasn't a simpler way, BTW (other than mtdram)) Logfs can use a block device directly, which still leaves loop. Enhancing block2mtd to work with files shouldn't be too hard. If anyone want a fun project to hack on... Jörn -- Data dominates. If you've chosen the right data structures and organized things well, the algorithms will almost always be self-evident. Data structures, not algorithms, are central to programming. -- Rob Pike -- 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: [PATCH 2.6.24] block2mtd: removing a device and typo fixes
2008-02-20 18:22:50 +0100, Jörn Engel: > On Wed, 20 February 2008 17:02:31 +, Stephane Chazelas wrote: > > > > sorry, I wasn't very clear. > > > > With "loop", you're doing an ioctl() to /dev/loop so that > > /dev/loop become a block device associated with a given file. > > > > Applying that strictly to block2mtd wouldn't make sense. > > > > At the moment, when you create a new block2mtd, the only thing > > you see is an entry in /proc/mtd. > > > > You don't access that mtd device directly (there's no > > /dev/mtd). Instead, you may access it via a /dev/mtdblock > > if you have "block2mtd" for instance. > > Actually, there is /dev/mtd. Enable CONFIG_MTD_CHAR. Yes, my point ;). "block2mtd" creates a "mtd" out of a block device and "mtdchar" and "mtdblock" create the "char" and "block" devices out of the "mtd". This is a different concept from "loop". With "loop", you make a block device out of a file, but you do the ioctl on the target loop block device itself. With block2mtd, you can't do that. > > Here, what you need, is an API that gets a block device (with fd > > or path) and an erase size and that returns a mtd identifier. > > Erase size is a real difference, agreed. Otherwise the loop analogy is > quite good. Occasionally people are asking for file->mtd translation as > well. [...] Actually, that's what I use block2mtd for, in combination with "loop" to mount jffs2 filesystem images (always wondered if there wasn't a simpler way, BTW (other than mtdram)) Cheers, Stephane -- 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: [PATCH 2.6.24] block2mtd: removing a device and typo fixes
On Wed, 20 February 2008 17:02:31 +, Stephane Chazelas wrote: > > sorry, I wasn't very clear. > > With "loop", you're doing an ioctl() to /dev/loop so that > /dev/loop become a block device associated with a given file. > > Applying that strictly to block2mtd wouldn't make sense. > > At the moment, when you create a new block2mtd, the only thing > you see is an entry in /proc/mtd. > > You don't access that mtd device directly (there's no > /dev/mtd). Instead, you may access it via a /dev/mtdblock > if you have "block2mtd" for instance. Actually, there is /dev/mtd. Enable CONFIG_MTD_CHAR. > Here, what you need, is an API that gets a block device (with fd > or path) and an erase size and that returns a mtd identifier. Erase size is a real difference, agreed. Otherwise the loop analogy is quite good. Occasionally people are asking for file->mtd translation as well. Jörn -- To announce that there must be no criticism of the President, or that we are to stand by the President, right or wrong, is not only unpatriotic and servile, but is morally treasonable to the American public. -- Theodore Roosevelt, Kansas City Star, 1918 -- 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: [PATCH 2.6.24] block2mtd: removing a device and typo fixes
2008-02-20 17:30:42 +0100, Jörn Engel: > On Wed, 20 February 2008 14:43:39 +, Stephane Chazelas wrote: > > > > note that for "loop", you have /dev/loop0, /dev/loop1... which > > makes it a pain to handle > > > > For block2mtd, you don't need several device files in /dev, you > > only need one to pass ioctls down to create mtd devices. > > > > That may end up creating new /dev devices via mtdblock or > > mtdblock_ro for instance. > > > > So I'm not sure reusing the "loop" ioctls is a good idea. > > /me notes that you dislike both existing interfaces and would prefer a > third. How likely is it that you will still like the new interface two > years down the road? How likely is it that everyone else will agree > with you? > > In the end, a painful interface is still less painful than a choice of > several incompatible ones. I used to think different and have burned my > fingers often enough to learn the lesson. :) [...] Hi Jörn, sorry, I wasn't very clear. With "loop", you're doing an ioctl() to /dev/loop so that /dev/loop become a block device associated with a given file. Applying that strictly to block2mtd wouldn't make sense. At the moment, when you create a new block2mtd, the only thing you see is an entry in /proc/mtd. You don't access that mtd device directly (there's no /dev/mtd). Instead, you may access it via a /dev/mtdblock if you have "block2mtd" for instance. Here, what you need, is an API that gets a block device (with fd or path) and an erase size and that returns a mtd identifier. Best regards, Stephane -- 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: [PATCH 2.6.24] block2mtd: removing a device and typo fixes
2008-02-20 17:42:27 +0100, Jörn Engel: > On Wed, 20 February 2008 14:36:46 +, Stephane Chazelas wrote: > > > > At the moment, when we bind a mtd device to a block device, we > > don't increase the refcount. When a mtdblock on a block2mtd, the > > refcount is not increased either (the mtdblock's one is I > > guess). > > That is a bug then. [...] Well, given that there is no API to unbind a mtd to a block device, otherwise, we would never be able to unload block2mtd. So fare, unloading block2mtd was the only way to unbind a mtd from a block device. Cheers, Stephane -- 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: [PATCH 2.6.24] block2mtd: removing a device and typo fixes
On Wed, 20 February 2008 14:36:46 +, Stephane Chazelas wrote: > > At the moment, when we bind a mtd device to a block device, we > don't increase the refcount. When a mtdblock on a block2mtd, the > refcount is not increased either (the mtdblock's one is I > guess). That is a bug then. Jörn -- The story so far: In the beginning the Universe was created. This has made a lot of people very angry and been widely regarded as a bad move. -- Douglas Adams -- 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: [PATCH 2.6.24] block2mtd: removing a device and typo fixes
On Wed, 20 February 2008 14:43:39 +, Stephane Chazelas wrote: > > note that for "loop", you have /dev/loop0, /dev/loop1... which > makes it a pain to handle > > For block2mtd, you don't need several device files in /dev, you > only need one to pass ioctls down to create mtd devices. > > That may end up creating new /dev devices via mtdblock or > mtdblock_ro for instance. > > So I'm not sure reusing the "loop" ioctls is a good idea. /me notes that you dislike both existing interfaces and would prefer a third. How likely is it that you will still like the new interface two years down the road? How likely is it that everyone else will agree with you? In the end, a painful interface is still less painful than a choice of several incompatible ones. I used to think different and have burned my fingers often enough to learn the lesson. :) Jörn -- Mac is for working, Linux is for Networking, Windows is for Solitaire! -- stolen from dc -- 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: [PATCH 2.6.24] block2mtd: removing a device and typo fixes
2008-02-19 23:33:38 +0100, Arnd Bergmann:
> On Tuesday 19 February 2008, you wrote:
> > > What about having a /dev/block2mtd (with owner/permissions that
> > > could allow non-root users to use it), with 2 ioctls:
> > >
> > > - one to "link" a block dev to a mtd that would take as
> > > parameter a fd to an open block dev (again allowing for
> > > flexible permissions) and would return the number of the
> > > allocated mtd and success/failure in errno. Upon sucess it
> > > would increase the refcnt of block2mtd.
> > >
> > > - and one to "release" the link. That would fail if the mtd is
> > > in use and decrease block2mtd's refcnt upon success.
> > >
> > > A bit like the loop devices (or /dev/ptmx) actually. What do you
> > > think?
> >
> > Could work. Passing the fd raises several alarm bells. Arnd, any
> > comments from you?
>
> Given that loop works in this way, I certainly see that as doable,
> but then I'd vote for using the existing ioctl semantics of
> LOOP_SET_FD and LOOP_DEL_FD on the mtdchar device, which already
> comes with an ioctl interface for mtd devices.
> I'd probably also allow the LOOP_{GET,SET}_STATUS{,64} commands,
> so you can actually use the existing losetup tool.
> That way, we wouldn't have to introduce a new API, just extend
> an existing one to work on more things.
[...]
Hi Arnd,
note that for "loop", you have /dev/loop0, /dev/loop1... which
makes it a pain to handle
For block2mtd, you don't need several device files in /dev, you
only need one to pass ioctls down to create mtd devices.
That may end up creating new /dev devices via mtdblock or
mtdblock_ro for instance.
So I'm not sure reusing the "loop" ioctls is a good idea.
Cheers,
Stephane
--
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: [PATCH 2.6.24] block2mtd: removing a device and typo fixes
2008-02-19 16:08:22 +0100, Jörn Engel: > [ Just returned home. ] Hi Jörn, I've got to admit I've been a little too busy to look at it myself. I'll send a patch for the obvious fixes soon though. [...] > > Well, yes that raised a concern to me, the "exit" function > > returns "void". If the del_mtd_device fails with EBUSY at the > > moment (such as when a /dev/mtdblock is mounted), we ignore > > it and go on with freeing everything leaving a dangling mtd. > > > > Is there a way around that? > > For module unload we should be safe. Errors are only returned if the > device doesn't exist (a clear bug) or if the device is still being used. > Module refcounting should prevent the latter case, so either way we have > a bug if del_mtd_device returns an error. At the moment, when we bind a mtd device to a block device, we don't increase the refcount. When a mtdblock on a block2mtd, the refcount is not increased either (the mtdblock's one is I guess). When you unload block2mtd, the block2mtd exit code tries and remove the mtd bindings. If it fails, it exits anyway, leaving some dangling stuff. That's why I suggested that the exit code doesn't do the cleaning but that the requirement of cleaning things up is put upon the user before he is allowed to unload the module (increasing the refcount every time block2mtd is used to map a mtd to a block device). > When removing the device via your proposed interface we should simply > return the error to userspace, if the interface permits. Sysfs doesn't > seem to permit error returns, so we should keep the device alive and do > nothing. Agreed, that's what I was doing in my patch. But I wasn't doing anything with the refcount, this was still handled as before, that is we relied on the exit code to do the clean up. Best regards, Stephane -- 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: [PATCH 2.6.24] block2mtd: removing a device and typo fixes
2008-02-19 23:33:38 +0100, Arnd Bergmann:
On Tuesday 19 February 2008, you wrote:
What about having a /dev/block2mtd (with owner/permissions that
could allow non-root users to use it), with 2 ioctls:
- one to link a block dev to a mtd that would take as
parameter a fd to an open block dev (again allowing for
flexible permissions) and would return the number of the
allocated mtd and success/failure in errno. Upon sucess it
would increase the refcnt of block2mtd.
- and one to release the link. That would fail if the mtd is
in use and decrease block2mtd's refcnt upon success.
A bit like the loop devices (or /dev/ptmx) actually. What do you
think?
Could work. Passing the fd raises several alarm bells. Arnd, any
comments from you?
Given that loop works in this way, I certainly see that as doable,
but then I'd vote for using the existing ioctl semantics of
LOOP_SET_FD and LOOP_DEL_FD on the mtdchar device, which already
comes with an ioctl interface for mtd devices.
I'd probably also allow the LOOP_{GET,SET}_STATUS{,64} commands,
so you can actually use the existing losetup tool.
That way, we wouldn't have to introduce a new API, just extend
an existing one to work on more things.
[...]
Hi Arnd,
note that for loop, you have /dev/loop0, /dev/loop1... which
makes it a pain to handle
For block2mtd, you don't need several device files in /dev, you
only need one to pass ioctls down to create mtd devices.
That may end up creating new /dev devices via mtdblock or
mtdblock_ro for instance.
So I'm not sure reusing the loop ioctls is a good idea.
Cheers,
Stephane
--
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: [PATCH 2.6.24] block2mtd: removing a device and typo fixes
2008-02-19 16:08:22 +0100, Jörn Engel: [ Just returned home. ] Hi Jörn, I've got to admit I've been a little too busy to look at it myself. I'll send a patch for the obvious fixes soon though. [...] Well, yes that raised a concern to me, the exit function returns void. If the del_mtd_device fails with EBUSY at the moment (such as when a /dev/mtdblockx is mounted), we ignore it and go on with freeing everything leaving a dangling mtd. Is there a way around that? For module unload we should be safe. Errors are only returned if the device doesn't exist (a clear bug) or if the device is still being used. Module refcounting should prevent the latter case, so either way we have a bug if del_mtd_device returns an error. At the moment, when we bind a mtd device to a block device, we don't increase the refcount. When a mtdblock on a block2mtd, the refcount is not increased either (the mtdblock's one is I guess). When you unload block2mtd, the block2mtd exit code tries and remove the mtd bindings. If it fails, it exits anyway, leaving some dangling stuff. That's why I suggested that the exit code doesn't do the cleaning but that the requirement of cleaning things up is put upon the user before he is allowed to unload the module (increasing the refcount every time block2mtd is used to map a mtd to a block device). When removing the device via your proposed interface we should simply return the error to userspace, if the interface permits. Sysfs doesn't seem to permit error returns, so we should keep the device alive and do nothing. Agreed, that's what I was doing in my patch. But I wasn't doing anything with the refcount, this was still handled as before, that is we relied on the exit code to do the clean up. Best regards, Stephane -- 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: [PATCH 2.6.24] block2mtd: removing a device and typo fixes
On Wed, 20 February 2008 14:43:39 +, Stephane Chazelas wrote: note that for loop, you have /dev/loop0, /dev/loop1... which makes it a pain to handle For block2mtd, you don't need several device files in /dev, you only need one to pass ioctls down to create mtd devices. That may end up creating new /dev devices via mtdblock or mtdblock_ro for instance. So I'm not sure reusing the loop ioctls is a good idea. /me notes that you dislike both existing interfaces and would prefer a third. How likely is it that you will still like the new interface two years down the road? How likely is it that everyone else will agree with you? In the end, a painful interface is still less painful than a choice of several incompatible ones. I used to think different and have burned my fingers often enough to learn the lesson. :) Jörn -- Mac is for working, Linux is for Networking, Windows is for Solitaire! -- stolen from dc -- 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: [PATCH 2.6.24] block2mtd: removing a device and typo fixes
On Wed, 20 February 2008 14:36:46 +, Stephane Chazelas wrote: At the moment, when we bind a mtd device to a block device, we don't increase the refcount. When a mtdblock on a block2mtd, the refcount is not increased either (the mtdblock's one is I guess). That is a bug then. Jörn -- The story so far: In the beginning the Universe was created. This has made a lot of people very angry and been widely regarded as a bad move. -- Douglas Adams -- 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: [PATCH 2.6.24] block2mtd: removing a device and typo fixes
2008-02-20 17:30:42 +0100, Jörn Engel: On Wed, 20 February 2008 14:43:39 +, Stephane Chazelas wrote: note that for loop, you have /dev/loop0, /dev/loop1... which makes it a pain to handle For block2mtd, you don't need several device files in /dev, you only need one to pass ioctls down to create mtd devices. That may end up creating new /dev devices via mtdblock or mtdblock_ro for instance. So I'm not sure reusing the loop ioctls is a good idea. /me notes that you dislike both existing interfaces and would prefer a third. How likely is it that you will still like the new interface two years down the road? How likely is it that everyone else will agree with you? In the end, a painful interface is still less painful than a choice of several incompatible ones. I used to think different and have burned my fingers often enough to learn the lesson. :) [...] Hi Jörn, sorry, I wasn't very clear. With loop, you're doing an ioctl() to /dev/loopx so that /dev/loopx become a block device associated with a given file. Applying that strictly to block2mtd wouldn't make sense. At the moment, when you create a new block2mtd, the only thing you see is an entry in /proc/mtd. You don't access that mtd device directly (there's no /dev/mtdx). Instead, you may access it via a /dev/mtdblockx if you have block2mtd for instance. Here, what you need, is an API that gets a block device (with fd or path) and an erase size and that returns a mtd identifier. Best regards, Stephane -- 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: [PATCH 2.6.24] block2mtd: removing a device and typo fixes
2008-02-20 18:22:50 +0100, Jörn Engel: On Wed, 20 February 2008 17:02:31 +, Stephane Chazelas wrote: sorry, I wasn't very clear. With loop, you're doing an ioctl() to /dev/loopx so that /dev/loopx become a block device associated with a given file. Applying that strictly to block2mtd wouldn't make sense. At the moment, when you create a new block2mtd, the only thing you see is an entry in /proc/mtd. You don't access that mtd device directly (there's no /dev/mtdx). Instead, you may access it via a /dev/mtdblockx if you have block2mtd for instance. Actually, there is /dev/mtdx. Enable CONFIG_MTD_CHAR. Yes, my point ;). block2mtd creates a mtd out of a block device and mtdchar and mtdblock create the char and block devices out of the mtd. This is a different concept from loop. With loop, you make a block device out of a file, but you do the ioctl on the target loop block device itself. With block2mtd, you can't do that. Here, what you need, is an API that gets a block device (with fd or path) and an erase size and that returns a mtd identifier. Erase size is a real difference, agreed. Otherwise the loop analogy is quite good. Occasionally people are asking for file-mtd translation as well. [...] Actually, that's what I use block2mtd for, in combination with loop to mount jffs2 filesystem images (always wondered if there wasn't a simpler way, BTW (other than mtdram)) Cheers, Stephane -- 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: [PATCH 2.6.24] block2mtd: removing a device and typo fixes
On Wed, 20 February 2008 17:02:31 +, Stephane Chazelas wrote: sorry, I wasn't very clear. With loop, you're doing an ioctl() to /dev/loopx so that /dev/loopx become a block device associated with a given file. Applying that strictly to block2mtd wouldn't make sense. At the moment, when you create a new block2mtd, the only thing you see is an entry in /proc/mtd. You don't access that mtd device directly (there's no /dev/mtdx). Instead, you may access it via a /dev/mtdblockx if you have block2mtd for instance. Actually, there is /dev/mtdx. Enable CONFIG_MTD_CHAR. Here, what you need, is an API that gets a block device (with fd or path) and an erase size and that returns a mtd identifier. Erase size is a real difference, agreed. Otherwise the loop analogy is quite good. Occasionally people are asking for file-mtd translation as well. Jörn -- To announce that there must be no criticism of the President, or that we are to stand by the President, right or wrong, is not only unpatriotic and servile, but is morally treasonable to the American public. -- Theodore Roosevelt, Kansas City Star, 1918 -- 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: [PATCH 2.6.24] block2mtd: removing a device and typo fixes
2008-02-20 17:42:27 +0100, Jörn Engel: On Wed, 20 February 2008 14:36:46 +, Stephane Chazelas wrote: At the moment, when we bind a mtd device to a block device, we don't increase the refcount. When a mtdblock on a block2mtd, the refcount is not increased either (the mtdblock's one is I guess). That is a bug then. [...] Well, given that there is no API to unbind a mtd to a block device, otherwise, we would never be able to unload block2mtd. So fare, unloading block2mtd was the only way to unbind a mtd from a block device. Cheers, Stephane -- 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: [PATCH 2.6.24] block2mtd: removing a device and typo fixes
On Tue, 19 February 2008 23:33:38 +0100, Arnd Bergmann wrote:
>
> Given that loop works in this way, I certainly see that as doable,
> but then I'd vote for using the existing ioctl semantics of
> LOOP_SET_FD and LOOP_DEL_FD on the mtdchar device, which already
> comes with an ioctl interface for mtd devices.
> I'd probably also allow the LOOP_{GET,SET}_STATUS{,64} commands,
> so you can actually use the existing losetup tool.
> That way, we wouldn't have to introduce a new API, just extend
> an existing one to work on more things.
I like this approach. It somewhat collides with the mtd principle of
having a seperate module for every 2-3 lines of code, but maybe that is
not a bad thing after all.
Onto my list of code to write on rainy afternoons (and secretly hoping
for others to do it instead).
Jörn
--
Mundie uses a textbook tactic of manipulation: start with some
reasonable talk, and lead the audience to an unreasonable conclusion.
-- Bruce Perens
--
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: [PATCH 2.6.24] block2mtd: removing a device and typo fixes
On Tuesday 19 February 2008, you wrote:
> > What about having a /dev/block2mtd (with owner/permissions that
> > could allow non-root users to use it), with 2 ioctls:
> >
> > - one to "link" a block dev to a mtd that would take as
> > parameter a fd to an open block dev (again allowing for
> > flexible permissions) and would return the number of the
> > allocated mtd and success/failure in errno. Upon sucess it
> > would increase the refcnt of block2mtd.
> >
> > - and one to "release" the link. That would fail if the mtd is
> > in use and decrease block2mtd's refcnt upon success.
> >
> > A bit like the loop devices (or /dev/ptmx) actually. What do you
> > think?
>
> Could work. Passing the fd raises several alarm bells. Arnd, any
> comments from you?
Given that loop works in this way, I certainly see that as doable,
but then I'd vote for using the existing ioctl semantics of
LOOP_SET_FD and LOOP_DEL_FD on the mtdchar device, which already
comes with an ioctl interface for mtd devices.
I'd probably also allow the LOOP_{GET,SET}_STATUS{,64} commands,
so you can actually use the existing losetup tool.
That way, we wouldn't have to introduce a new API, just extend
an existing one to work on more things.
Arnd <><
--
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: [PATCH 2.6.24] block2mtd: removing a device and typo fixes
[ Just returned home. ] On Tue, 12 February 2008 16:10:34 +, Stephane Chazelas wrote: > > OK, I can do that. Would the "simple" fix go to the > [EMAIL PROTECTED] Trivial Patch Monkey? That or to me or to dwmw2... I'm not too picky about the path, as long as it gets merged eventually. > > The core of remove_device_by_name() is shared with block2mtd_exit(), > > so a common helper would be good. Your error handling is better, so > > let's keep that version. > > Well, yes that raised a concern to me, the "exit" function > returns "void". If the del_mtd_device fails with EBUSY at the > moment (such as when a /dev/mtdblock is mounted), we ignore > it and go on with freeing everything leaving a dangling mtd. > > Is there a way around that? For module unload we should be safe. Errors are only returned if the device doesn't exist (a clear bug) or if the device is still being used. Module refcounting should prevent the latter case, so either way we have a bug if del_mtd_device returns an error. When removing the device via your proposed interface we should simply return the error to userspace, if the interface permits. Sysfs doesn't seem to permit error returns, so we should keep the device alive and do nothing. > Another problem is that it's not easy to check whether a mtd > creation was successful or not. Basically, you have to write to > a /sys file and then parse /proc/mtd to get the result. Agreed, sysfs' lack of error indication isn't ideal. > What about having a /dev/block2mtd (with owner/permissions that > could allow non-root users to use it), with 2 ioctls: > > - one to "link" a block dev to a mtd that would take as > parameter a fd to an open block dev (again allowing for > flexible permissions) and would return the number of the > allocated mtd and success/failure in errno. Upon sucess it > would increase the refcnt of block2mtd. > > - and one to "release" the link. That would fail if the mtd is > in use and decrease block2mtd's refcnt upon success. > > A bit like the loop devices (or /dev/ptmx) actually. What do you > think? Could work. Passing the fd raises several alarm bells. Arnd, any comments from you? In general I'd like to see some good reasons for adding an ioctl (or any other) interface first. Creating interfaces is hard and you rarely get a second chance to fix the mess you created before you knew all the consequenses. > (also, with the /sys interface, isn't there a potential problem > with chroots wrt the path given to the /sys file?) There may be. Can you check if there is? Jörn -- Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it. -- Brian W. Kernighan -- 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: [PATCH 2.6.24] block2mtd: removing a device and typo fixes
[ Just returned home. ] On Tue, 12 February 2008 16:10:34 +, Stephane Chazelas wrote: OK, I can do that. Would the simple fix go to the [EMAIL PROTECTED] Trivial Patch Monkey? That or to me or to dwmw2... I'm not too picky about the path, as long as it gets merged eventually. The core of remove_device_by_name() is shared with block2mtd_exit(), so a common helper would be good. Your error handling is better, so let's keep that version. Well, yes that raised a concern to me, the exit function returns void. If the del_mtd_device fails with EBUSY at the moment (such as when a /dev/mtdblockx is mounted), we ignore it and go on with freeing everything leaving a dangling mtd. Is there a way around that? For module unload we should be safe. Errors are only returned if the device doesn't exist (a clear bug) or if the device is still being used. Module refcounting should prevent the latter case, so either way we have a bug if del_mtd_device returns an error. When removing the device via your proposed interface we should simply return the error to userspace, if the interface permits. Sysfs doesn't seem to permit error returns, so we should keep the device alive and do nothing. Another problem is that it's not easy to check whether a mtd creation was successful or not. Basically, you have to write to a /sys file and then parse /proc/mtd to get the result. Agreed, sysfs' lack of error indication isn't ideal. What about having a /dev/block2mtd (with owner/permissions that could allow non-root users to use it), with 2 ioctls: - one to link a block dev to a mtd that would take as parameter a fd to an open block dev (again allowing for flexible permissions) and would return the number of the allocated mtd and success/failure in errno. Upon sucess it would increase the refcnt of block2mtd. - and one to release the link. That would fail if the mtd is in use and decrease block2mtd's refcnt upon success. A bit like the loop devices (or /dev/ptmx) actually. What do you think? Could work. Passing the fd raises several alarm bells. Arnd, any comments from you? In general I'd like to see some good reasons for adding an ioctl (or any other) interface first. Creating interfaces is hard and you rarely get a second chance to fix the mess you created before you knew all the consequenses. (also, with the /sys interface, isn't there a potential problem with chroots wrt the path given to the /sys file?) There may be. Can you check if there is? Jörn -- Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it. -- Brian W. Kernighan -- 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: [PATCH 2.6.24] block2mtd: removing a device and typo fixes
On Tuesday 19 February 2008, you wrote:
What about having a /dev/block2mtd (with owner/permissions that
could allow non-root users to use it), with 2 ioctls:
- one to link a block dev to a mtd that would take as
parameter a fd to an open block dev (again allowing for
flexible permissions) and would return the number of the
allocated mtd and success/failure in errno. Upon sucess it
would increase the refcnt of block2mtd.
- and one to release the link. That would fail if the mtd is
in use and decrease block2mtd's refcnt upon success.
A bit like the loop devices (or /dev/ptmx) actually. What do you
think?
Could work. Passing the fd raises several alarm bells. Arnd, any
comments from you?
Given that loop works in this way, I certainly see that as doable,
but then I'd vote for using the existing ioctl semantics of
LOOP_SET_FD and LOOP_DEL_FD on the mtdchar device, which already
comes with an ioctl interface for mtd devices.
I'd probably also allow the LOOP_{GET,SET}_STATUS{,64} commands,
so you can actually use the existing losetup tool.
That way, we wouldn't have to introduce a new API, just extend
an existing one to work on more things.
Arnd
--
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: [PATCH 2.6.24] block2mtd: removing a device and typo fixes
On Tue, 19 February 2008 23:33:38 +0100, Arnd Bergmann wrote:
Given that loop works in this way, I certainly see that as doable,
but then I'd vote for using the existing ioctl semantics of
LOOP_SET_FD and LOOP_DEL_FD on the mtdchar device, which already
comes with an ioctl interface for mtd devices.
I'd probably also allow the LOOP_{GET,SET}_STATUS{,64} commands,
so you can actually use the existing losetup tool.
That way, we wouldn't have to introduce a new API, just extend
an existing one to work on more things.
I like this approach. It somewhat collides with the mtd principle of
having a seperate module for every 2-3 lines of code, but maybe that is
not a bad thing after all.
Onto my list of code to write on rainy afternoons (and secretly hoping
for others to do it instead).
Jörn
--
Mundie uses a textbook tactic of manipulation: start with some
reasonable talk, and lead the audience to an unreasonable conclusion.
-- Bruce Perens
--
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: [PATCH 2.6.24] block2mtd: removing a device and typo fixes
2008-02-12 16:21:24 +0100, Jörn Engel: > On Tue, 12 February 2008 13:47:51 +, Stephane Chazelas wrote: > > > > this patch addresses a number of small issues mainly regarding > > the output made by this driver to dmesg: > > - Some of the "blkmtd"'s had not been changed to "block2mtd" > > which caused display problem > > - the parse_err() macro was displaying "block2mtd: " twice > > Fairly obvious fixes. > > > Also, one can add a block2mtd mtd device with things like: > > > > echo /dev/loop3,$((256*1024)) | > > sudo tee /sys/module/block2mtd/parameters/block2mtd > > > > but individual mtds cannot be removed. You can only do a > > modprobe -r block2mtd to remove *all* the block2mtd mtds. > > > > This patch proposes to add the cabability with: > > > > echo /dev/loop3,remove | > > sudo tee /sys/module/block2mtd/parameters/block2mtd > > Sounds sane enough. But I do have some reservations about the > implementation. It would be best if you split the patch in two. One > with the obvious stuff above and one for this. Hi Jörn, OK, I can do that. Would the "simple" fix go to the [EMAIL PROTECTED] Trivial Patch Monkey? > The core of remove_device_by_name() is shared with block2mtd_exit(), > so a common helper would be good. Your error handling is better, so > let's keep that version. Well, yes that raised a concern to me, the "exit" function returns "void". If the del_mtd_device fails with EBUSY at the moment (such as when a /dev/mtdblock is mounted), we ignore it and go on with freeing everything leaving a dangling mtd. Is there a way around that? Another problem is that it's not easy to check whether a mtd creation was successful or not. Basically, you have to write to a /sys file and then parse /proc/mtd to get the result. What about having a /dev/block2mtd (with owner/permissions that could allow non-root users to use it), with 2 ioctls: - one to "link" a block dev to a mtd that would take as parameter a fd to an open block dev (again allowing for flexible permissions) and would return the number of the allocated mtd and success/failure in errno. Upon sucess it would increase the refcnt of block2mtd. - and one to "release" the link. That would fail if the mtd is in use and decrease block2mtd's refcnt upon success. A bit like the loop devices (or /dev/ptmx) actually. What do you think? (also, with the /sys interface, isn't there a potential problem with chroots wrt the path given to the /sys file?) > And independently of your patch a mutex protecting the device list from > simultaneous modifications would be good to have. > > Side note: I may not have internet access until 19th or so. [...] I'll dig a little deeper, but I think I'll need some advice/help at some point, I'm not a Linux kernel expert. Regards, Stephane -- 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: [PATCH 2.6.24] block2mtd: removing a device and typo fixes
On Tue, 12 February 2008 13:47:51 +, Stephane Chazelas wrote: > > this patch addresses a number of small issues mainly regarding > the output made by this driver to dmesg: > - Some of the "blkmtd"'s had not been changed to "block2mtd" > which caused display problem > - the parse_err() macro was displaying "block2mtd: " twice Fairly obvious fixes. > Also, one can add a block2mtd mtd device with things like: > > echo /dev/loop3,$((256*1024)) | > sudo tee /sys/module/block2mtd/parameters/block2mtd > > but individual mtds cannot be removed. You can only do a > modprobe -r block2mtd to remove *all* the block2mtd mtds. > > This patch proposes to add the cabability with: > > echo /dev/loop3,remove | > sudo tee /sys/module/block2mtd/parameters/block2mtd Sounds sane enough. But I do have some reservations about the implementation. It would be best if you split the patch in two. One with the obvious stuff above and one for this. The core of remove_device_by_name() is shared with block2mtd_exit(), so a common helper would be good. Your error handling is better, so let's keep that version. And independently of your patch a mutex protecting the device list from simultaneous modifications would be good to have. Side note: I may not have internet access until 19th or so. Jörn -- Rules of Optimization: Rule 1: Don't do it. Rule 2 (for experts only): Don't do it yet. -- M.A. Jackson -- 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/
[PATCH 2.6.24] block2mtd: removing a device and typo fixes
Hi Joern,
this patch addresses a number of small issues mainly regarding
the output made by this driver to dmesg:
- Some of the "blkmtd"'s had not been changed to "block2mtd"
which caused display problem
- the parse_err() macro was displaying "block2mtd: " twice
Also, one can add a block2mtd mtd device with things like:
echo /dev/loop3,$((256*1024)) |
sudo tee /sys/module/block2mtd/parameters/block2mtd
but individual mtds cannot be removed. You can only do a
modprobe -r block2mtd to remove *all* the block2mtd mtds.
This patch proposes to add the cabability with:
echo /dev/loop3,remove |
sudo tee /sys/module/block2mtd/parameters/block2mtd
Signed-off-by: Stephane Chazelas <[EMAIL PROTECTED]>
--- drivers/mtd/devices/block2mtd.c~2007-09-11 03:50:29.0 +0100
+++ drivers/mtd/devices/block2mtd.c 2008-02-12 13:30:16.0 +
@@ -305,7 +305,7 @@ static struct block2mtd_dev *add_device(
}
list_add(>list, _device_list);
INFO("mtd%d: [%s] erase_size = %dKiB [%d]", dev->mtd.index,
- dev->mtd.name + strlen("blkmtd: "),
+ dev->mtd.name + strlen("block2mtd: "),
dev->mtd.erasesize >> 10, dev->mtd.erasesize);
return dev;
@@ -366,9 +366,9 @@ static inline void kill_final_newline(ch
}
-#define parse_err(fmt, args...) do { \
- ERROR("block2mtd: " fmt "\n", ## args); \
- return 0; \
+#define parse_err(fmt, args...) do { \
+ ERROR(fmt, ## args);\
+ return 0; \
} while (0)
#ifndef MODULE
@@ -376,6 +376,31 @@ static int block2mtd_init_called = 0;
static char block2mtd_paramline[80 + 12]; /* 80 for device, 12 for erase size
*/
#endif
+static void remove_device_by_name(const char *name)
+{
+ struct list_head *pos, *next;
+ int name_offset = strlen("block2mtd: ");
+
+ list_for_each_safe(pos, next, _device_list) {
+ struct block2mtd_dev *dev = list_entry(pos, typeof(*dev), list);
+ if (!strcmp(name, dev->mtd.name + name_offset)) {
+ int err;
+ block2mtd_sync(>mtd);
+ err = del_mtd_device(>mtd);
+ if (err == 0) {
+ INFO("mtd%d: [%s] removed",
+ dev->mtd.index, name);
+ list_del(>list);
+ block2mtd_free_device(dev);
+ } else
+ ERROR("mtd%d: [%s] cannot remove: %d",
+ dev->mtd.index, name, err);
+
+ return;
+ }
+ }
+ ERROR("no such device: %s", name);
+}
static int block2mtd_setup2(const char *val)
{
@@ -406,6 +431,10 @@ static int block2mtd_setup2(const char *
parse_err("device name too long");
if (token[1]) {
+ if (!strcmp("remove", token[1])) {
+ remove_device_by_name(name);
+ return 0;
+ }
ret = parse_num(_size, token[1]);
if (ret) {
kfree(name);
@@ -474,7 +503,7 @@ static void __devexit block2mtd_exit(voi
block2mtd_sync(>mtd);
del_mtd_device(>mtd);
INFO("mtd%d: [%s] removed", dev->mtd.index,
- dev->mtd.name + strlen("blkmtd: "));
+ dev->mtd.name + strlen("block2mtd: "));
list_del(>list);
block2mtd_free_device(dev);
}
--
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: [PATCH 2.6.24] block2mtd: removing a device and typo fixes
2008-02-12 16:21:24 +0100, Jörn Engel: On Tue, 12 February 2008 13:47:51 +, Stephane Chazelas wrote: this patch addresses a number of small issues mainly regarding the output made by this driver to dmesg: - Some of the blkmtd's had not been changed to block2mtd which caused display problem - the parse_err() macro was displaying block2mtd: twice Fairly obvious fixes. Also, one can add a block2mtd mtd device with things like: echo /dev/loop3,$((256*1024)) | sudo tee /sys/module/block2mtd/parameters/block2mtd but individual mtds cannot be removed. You can only do a modprobe -r block2mtd to remove *all* the block2mtd mtds. This patch proposes to add the cabability with: echo /dev/loop3,remove | sudo tee /sys/module/block2mtd/parameters/block2mtd Sounds sane enough. But I do have some reservations about the implementation. It would be best if you split the patch in two. One with the obvious stuff above and one for this. Hi Jörn, OK, I can do that. Would the simple fix go to the [EMAIL PROTECTED] Trivial Patch Monkey? The core of remove_device_by_name() is shared with block2mtd_exit(), so a common helper would be good. Your error handling is better, so let's keep that version. Well, yes that raised a concern to me, the exit function returns void. If the del_mtd_device fails with EBUSY at the moment (such as when a /dev/mtdblockx is mounted), we ignore it and go on with freeing everything leaving a dangling mtd. Is there a way around that? Another problem is that it's not easy to check whether a mtd creation was successful or not. Basically, you have to write to a /sys file and then parse /proc/mtd to get the result. What about having a /dev/block2mtd (with owner/permissions that could allow non-root users to use it), with 2 ioctls: - one to link a block dev to a mtd that would take as parameter a fd to an open block dev (again allowing for flexible permissions) and would return the number of the allocated mtd and success/failure in errno. Upon sucess it would increase the refcnt of block2mtd. - and one to release the link. That would fail if the mtd is in use and decrease block2mtd's refcnt upon success. A bit like the loop devices (or /dev/ptmx) actually. What do you think? (also, with the /sys interface, isn't there a potential problem with chroots wrt the path given to the /sys file?) And independently of your patch a mutex protecting the device list from simultaneous modifications would be good to have. Side note: I may not have internet access until 19th or so. [...] I'll dig a little deeper, but I think I'll need some advice/help at some point, I'm not a Linux kernel expert. Regards, Stephane -- 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: [PATCH 2.6.24] block2mtd: removing a device and typo fixes
On Tue, 12 February 2008 13:47:51 +, Stephane Chazelas wrote: this patch addresses a number of small issues mainly regarding the output made by this driver to dmesg: - Some of the blkmtd's had not been changed to block2mtd which caused display problem - the parse_err() macro was displaying block2mtd: twice Fairly obvious fixes. Also, one can add a block2mtd mtd device with things like: echo /dev/loop3,$((256*1024)) | sudo tee /sys/module/block2mtd/parameters/block2mtd but individual mtds cannot be removed. You can only do a modprobe -r block2mtd to remove *all* the block2mtd mtds. This patch proposes to add the cabability with: echo /dev/loop3,remove | sudo tee /sys/module/block2mtd/parameters/block2mtd Sounds sane enough. But I do have some reservations about the implementation. It would be best if you split the patch in two. One with the obvious stuff above and one for this. The core of remove_device_by_name() is shared with block2mtd_exit(), so a common helper would be good. Your error handling is better, so let's keep that version. And independently of your patch a mutex protecting the device list from simultaneous modifications would be good to have. Side note: I may not have internet access until 19th or so. Jörn -- Rules of Optimization: Rule 1: Don't do it. Rule 2 (for experts only): Don't do it yet. -- M.A. Jackson -- 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/
[PATCH 2.6.24] block2mtd: removing a device and typo fixes
Hi Joern,
this patch addresses a number of small issues mainly regarding
the output made by this driver to dmesg:
- Some of the blkmtd's had not been changed to block2mtd
which caused display problem
- the parse_err() macro was displaying block2mtd: twice
Also, one can add a block2mtd mtd device with things like:
echo /dev/loop3,$((256*1024)) |
sudo tee /sys/module/block2mtd/parameters/block2mtd
but individual mtds cannot be removed. You can only do a
modprobe -r block2mtd to remove *all* the block2mtd mtds.
This patch proposes to add the cabability with:
echo /dev/loop3,remove |
sudo tee /sys/module/block2mtd/parameters/block2mtd
Signed-off-by: Stephane Chazelas [EMAIL PROTECTED]
--- drivers/mtd/devices/block2mtd.c~2007-09-11 03:50:29.0 +0100
+++ drivers/mtd/devices/block2mtd.c 2008-02-12 13:30:16.0 +
@@ -305,7 +305,7 @@ static struct block2mtd_dev *add_device(
}
list_add(dev-list, blkmtd_device_list);
INFO(mtd%d: [%s] erase_size = %dKiB [%d], dev-mtd.index,
- dev-mtd.name + strlen(blkmtd: ),
+ dev-mtd.name + strlen(block2mtd: ),
dev-mtd.erasesize 10, dev-mtd.erasesize);
return dev;
@@ -366,9 +366,9 @@ static inline void kill_final_newline(ch
}
-#define parse_err(fmt, args...) do { \
- ERROR(block2mtd: fmt \n, ## args); \
- return 0; \
+#define parse_err(fmt, args...) do { \
+ ERROR(fmt, ## args);\
+ return 0; \
} while (0)
#ifndef MODULE
@@ -376,6 +376,31 @@ static int block2mtd_init_called = 0;
static char block2mtd_paramline[80 + 12]; /* 80 for device, 12 for erase size
*/
#endif
+static void remove_device_by_name(const char *name)
+{
+ struct list_head *pos, *next;
+ int name_offset = strlen(block2mtd: );
+
+ list_for_each_safe(pos, next, blkmtd_device_list) {
+ struct block2mtd_dev *dev = list_entry(pos, typeof(*dev), list);
+ if (!strcmp(name, dev-mtd.name + name_offset)) {
+ int err;
+ block2mtd_sync(dev-mtd);
+ err = del_mtd_device(dev-mtd);
+ if (err == 0) {
+ INFO(mtd%d: [%s] removed,
+ dev-mtd.index, name);
+ list_del(dev-list);
+ block2mtd_free_device(dev);
+ } else
+ ERROR(mtd%d: [%s] cannot remove: %d,
+ dev-mtd.index, name, err);
+
+ return;
+ }
+ }
+ ERROR(no such device: %s, name);
+}
static int block2mtd_setup2(const char *val)
{
@@ -406,6 +431,10 @@ static int block2mtd_setup2(const char *
parse_err(device name too long);
if (token[1]) {
+ if (!strcmp(remove, token[1])) {
+ remove_device_by_name(name);
+ return 0;
+ }
ret = parse_num(erase_size, token[1]);
if (ret) {
kfree(name);
@@ -474,7 +503,7 @@ static void __devexit block2mtd_exit(voi
block2mtd_sync(dev-mtd);
del_mtd_device(dev-mtd);
INFO(mtd%d: [%s] removed, dev-mtd.index,
- dev-mtd.name + strlen(blkmtd: ));
+ dev-mtd.name + strlen(block2mtd: ));
list_del(dev-list);
block2mtd_free_device(dev);
}
--
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/
