Re: [PATCH] Embedded bios FTL

["Jörn Engel" <joern@wohnheim.fh-wedel.de>]

On Thu, 16 June 2005 13:54:59 +0200, Sean Young wrote:
> On Thu, Jun 16, 2005 at 12:29:05PM +0200, Joern Engel wrote:
> > 
> > An ioctl() would have a *really* hard time to make it into the kernel.
> 
> I agree that ioctl()s are ugly, but it does have the advantage that it 
> is accessible from user-space. Excuse my ignorance, but what is the 
> motivation for this?

Past experience, mostly.  95% of all ioctl() uses are for Crap(tm).
Mostly because people having some stupid idea can easily add an
ioctl() and have a hard time adding a new syscall or similar.

After a while, people caught up to this and by today, a new ioctl()
raises the red flag that someone stupid is trying to do something
stupid and should not be allowed to do so.

For the remaining 5% of good ideas, an ioctl number has no advantage
over a new function with a self-explaining name.

> > What you could do, however, might be something similar to this:
> > 
> > o Add an erase() function to stuct block_device_operations
> > o Have fat call that function whenever a block is know unused.
> > o Make sure only to call the function, if it's non-NULL.  Maybe a
> >   wrapper, maybe just
> > 	if (bd_ops->erase)
> > 		bd_ops->erase(block);
> >   inside fs/fat/.
> > o Implement erase() for your ftl driver to do something smart.
> > 
> > Be careful, though.  I haven't worked on block devices for a very long
> > time and could be talking out of my arse.  If you send such a patch to
> > akpm and get flamed into a pile of ashes - don't blame me. ;)
> 
> I'll have to spend more time looking at the block devices/bio code 
> before I can start. :)
> 
> erase() sounds rather mtd-specific. Wouldn't stale() be better?

You're right.  Even for mtd, erase would be the wrong name.  The
semantic is not to erase the full erase block (and to do it now,
imperatively) but to return control over a partial erase block to the
ftl.  Hmm.

For block devices, the semantic is that no read() to this block will
happen before the next write() to it.  forget() might be a decent name
as well.  Then the block device has the option to change the data
within this block as it pleases.  If the next read() happens before
the next write(), random data will be returned.

PS: Yeah, I know, block devices have request(), instead of read() and
write().  Same thing.

Jörn

-- 
The only real mistake is the one from which we learn nothing.
-- John Powell