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

[Paul M. <pm...@mv...>]

On Sat, Jan 26, 2002 at 04:26:51PM -0800, Fredrik Hubinette wrote:
> Any complaints about the new maple stuff so far?

Actually, haven't had too much of a chance to play with it yet.. will proba=
bly
get around to it soon..

> I've started reading up on block and mtd devices,
> and it seems to me that the mtd subsystem really
> isn't very well suited for writing a VMU driver.
>=20
Curious how you come to this conclusion, considering the MTD subsystem's ve=
ry
purpose is for managing things like the VMU..

> 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.
>=20
No, this is not the MTD subsystem. MTD supports many different types of
devices.. the mapping driver is really nothing more than something that dea=
ls
with underlying access to the device. ie, it generally needs to manage thin=
gs
like varying offsets and such for read/write requests..

The one byte at a time thing isn't true either, I only implemented an 8-bit
read/write to demonstrate how to deal with things.. the whole driver was a
proof of concept that was pending a real maple implementation, and is still=
 in
need of a bit of rework. Though full 8/16/32bit requests are fully supporte=
d..

> In my oppinion it would seem better to use a block device
> driver, but this may have other traps of course.

MTD fully supports block devices. Devices are generally registered through
mtdchar, which gives character device access to registered devices.. but you
can just as easily build in mtdblock support, load that, and have all your
registered devices accessible as block devices.

> 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.....
>=20
Size is static for all VMU's, since even the banked ones are only toggleable
via a hardware switch. As far as block size (as far as the fs is concerned),
this can all be mapped over top of the VMU flash.. all access to the device=
 is
forced through maple blocks anyways, so it really doesn't matter what you w=
ant
to deal with your fs block size as.. it all gets wrapped in the end..

> 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.).
>=20
Why would you want to store any of this information in a block on the devic=
e?
Your superblock already does all of this for you. Though for things like the
VMU file system, where the superblock resides at the _end_ of the flash ..
things get a little wierder.

> And, before I forget: If I do make a vmu driver, what major/minor
> numbers should I use? In theory you can connect 24 vmus to a
> dreamcast, so I'll need at least 24 separate devices. (Alternatively,
> I could create *one* device node which maps all the vmus into one
> address space, but I would only do that as a last resort...)
>=20
MTD already deals with this. Don't side step it. And if you're lucky .. I'll
even find the free time to fix my driver to work with your maple code, and
then you won't need to worry about this at all. (This is also why I told yo=
u a
good while ago that a driver was already in place and was merely in need of=
 a
bit of fixing up.. reinventing the wheel is a completely useless activity
here).

Regards,

--=20
Paul Mundt <pm...@mv...>
MontaVista Software, Inc.