dwmw2 at infradead.org
Mon Apr 10 05:58:52 EDT 2000
I've been thinking about this over the weekend.
I think we can restore get_mtd_device(), but is _has_ to increase the MTD
device's use count - hence it has to be coupled with a put_mtd_device().
Also, users like FTL cannot assume that the mtd_info struct will be present
for a given MTD when ftl_open() is called - it may be in the process of
being removed on another processor.
So in the _open() routine, they must attempt try_inc_mod_count(), which I'm
going to wrap in another function mtd_inc_use_count() so that I can later
deal with non-modular drivers which can go away (PCMCIA, anything else
User modules _must_ be able to deal with mtd_inc_use_count() failing. If
this happens, the mtd_info struct must be considered invalid, and not
dereferenced at all.
So I reckon we want something like the following:
struct mtd_info *get_mtd_device(struct mtd_info *mtd, int num);
This _must_ be called with the mtd_table_mutex not held, i.e. not from an
add/remove notify function. If <mtd> is NULL, it returns the MTD at minor
<num>, and if <num> is -1, it scans the list for the MTD driver which has
its struct mtd_info at location <mtd>.
On success, it returns a pointer to the struct mtd_info, on failure it
If both <mtd> and <num> are set, it checks that the MTD driver with minor
<num> has its struct mtd_info at <mtd>, and returns NULL if they don't
The reason for having two parameters rather than just the number is as
We need the number, because things like jffs, mtdblock and mtdchar when I
split it from the core code will want to get an MTD driver directly from
the minor number without using the notify functions to maintain a copy of
the mtd_table (mtdblock currently does this and it's horrible).
We cannot make do with _just_ the number, because on SMP machines, a driver
may have gone away and another been loaded in the same place - so user
modules can't just use the number to get a handle on the same MTD later.
They have to check that they've actually got the same one back.
We could actually provide just the number and force all the MTD user
modules to do the check themselves, I suppose, but doing the check for them
Couple it with
int put_mtd_device(struct mtd_info *mtd);
I can't actually think of any possible reason for failure that the caller
would be able to do anything about, so I may switch that to return void.
If I don't hear any complaints, I'll implement this just as soon as I've
provided some paperwork to get the boss off my back.
To unsubscribe, send "unsubscribe mtd" to majordomo at infradead.org
More information about the linux-mtd