Re: Killing JFFS under 2.2

[Alexander Larsson <alex@xxxxxxx.se>]

On Thu, 27 Jul 2000, Sébastien Côté wrote:

> Finn Hakansson wrote:
> > 
> > Hi Björn!
> > 
> > 1. Of course that is right. What I meant was that the bug that caused this to
> > happen was more important to find than to be able to recover from it. It makes
> > the file system more robust if we're able to catch strange things on the flash
> > during the scan. That I agree on.
> > 
> > Perhaps we should take a new look at the jffs_scan_flash routine? When one
> > thinks about it, even funnier JFFS images could be constructed in order to see
> > if the scanning works.
> > 
> > 2. I don't understand this myself either. It's funny. It's just like if
> > schedule() or something has been called somewhere. The code that we use is not
> > _exactly_ the same as the MTD folks are using.
> 
> The function flash_erase_region has been rewritten by someone
> (presumably Alexander Larsson) for MTD.  In the MTD version, there's :
> 
> schedule(); /* Wait for flash to finish. */
> /* FIXME: We could have been interrupted here. We don't deal with it */
> remove_wait_queue(&wait_q, &wait);
> 
> kfree(erase);
> return 0;


Yes, I've written that. But the original flash_erase_region can also
sleep (as can any MTD call too):

int
flash_erase_region(kdev_t dev, __u32 offset, __u32 size)
{
 ...

	flash_safe_acquire(part);
	do {
		flash_init_erase(erase_start, size);

		while (flash_is_busy((flashptr)part->chip->start)) {
			current->state = TASK_INTERRUPTIBLE;
			current->timeout = jiffies + HZ / 2;
			schedule();
		}


/ Alex