Re: [linuxdc-dev] VMU driver (Better maple)

[Fredrik H. <hu...@hu...>]

> > In particular, the mtd subsystem seems to use driver api
> > which writes one byte at a time, which is something
> > I would really really like to avoid in a VMU driver.
> > 
> 
> Where did you see this?  That MTD couldn't handle block devices?

Well, I might be reading the whole thing wrong, but as I understand
the code, it provides both char and block devices for each mtd device.
However, the mtd map handler has a byte-based interface which seems
like a lot of extra work to implement. This may however be incorrect.
I will do some more reading, but maybe someone more knowledge can save
me some trouble by pointing me in the right direction?

If this is indeed a misunderstanding on my behalf, then I will definitely
use the MTD subsystem since that is probably where vmus *should* be
integrated.

> > In my oppinion it would seem better to use a block device
> > driver, but this may have other traps of course.
> > One particular issue with a VMU driver is that it needs
> > to convey some meta-information (size, block size, root
> > block location etc.) to the reader/filesystem. One way
> > to support this would be to use an ioctl, but I'm not sure
> > that would be the best way because then loopbacks would
> > be impossible once a VMU filesystem is written.....
> > 
> 
> How is conveying metainformation different than any other block device in
> existance?  I'm not sure I follow.  If you dd from a CD-ROM drive to a
> file, you'll only get the size of that CD - the metainformation is
> privately manipulated by the block driver itself.

It's not that different. But with a cdrom you *know* where the root
block is without asking the block device. If you dd a iso9660 fs
to a file, you can still mount it using the loopback device.

On the other hand to be strictly compliant, a dreamcast vmu filesystem
has to ask the device where the root block is. This meta-information
would not survive a 'dd' operation, and thus the file would not be
loopback-mountable unless you specified where the root block is manually.

Of course specifying the root block manually would probably be acceptable.
Since almost all VMU's have the root block in the same place, a reasonable
default would practically solve the problem.

> > An alternative solution (which is not pretty, but it works)
> > would be to map the meta-information into block 0 and then
> > map block 0 of the VMU into block 1 of the block device
> > (etc. etc.).
> > 
> 
> Map where?  I thought you ditched MTD :P.  Just kidding.  I'm not so sure
> you want to give up on MTD, have you taken a look at the initial work Paul
> has done in CVS?  

I have looked at it. I may not understand it properly, but it seems
very incomplete and based on reading/writing one byte at a time, which
would be extremely slow. It was part of the reason I thought the mtdmap
API was byte-based.


        /Fredrik Hubinette