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

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

On Sat, Jan 26, 2002 at 10:39:16PM -0800, Fredrik Hubinette wrote:
> I don't want 8/16/32 bit requests.
> A pure block device would only have to service a whole block at a
> time, which would be much easier.
>=20
As far as speed. 32bit requests are just fine as well. You have no performa=
nce
gains going the block-aligned route. Though you're free to profile this and
prove me wrong if you wish.

> > MTD fully supports block devices. Devices are generally registered thro=
ugh
> > mtdchar, which gives character device access to registered devices.. bu=
t you
> > can just as easily build in mtdblock support, load that, and have all y=
our
> > registered devices accessible as block devices.
>=20
> But can you write a low-level mtd driver which doesn't have to
> be able to read one byte at a time?
>=20
You don't _have_ to do byte access at all. You're free to do 16bit and 32bit
requests all day long. Again, the 8bit read/write routine in the driver was
simply there as an example of how to wrap things. I can add 16/32bit support
if it'll really make you happy.

> > Size is static for all VMU's, since even the banked ones are only toggl=
eable
> > via a hardware switch. As far as block size (as far as the fs is concer=
ned),
> > this can all be mapped over top of the VMU flash.. all access to the de=
vice is
> > forced through maple blocks anyways, so it really doesn't matter what y=
ou want
> > to deal with your fs block size as.. it all gets wrapped in the end..
>=20
> Actually, different size VMUs are supported, but as far as I know, all
> existing ones are the same size.  The fact that everything is forced
> to maple blocks is the very reason I think a simple block device driver
> would be the easiest.
>=20
Well, that's fine and all. Things like block size and number of blocks are
completely configurable through my driver, so that's a non-issue.

> > Why would you want to store any of this information in a block on the d=
evice?
> > Your superblock already does all of this for you. Though for things lik=
e the
> > VMU file system, where the superblock resides at the _end_ of the flash=
 ..
> > things get a little wierder.
>=20
> The superblock in the VMU can in fact be stored anywhere on the vmu.
> There is a special maple call which says where the superblock is. That
> is why meta information is needed.=20
>=20
And the point of this is .. ? All stock unmodified VMU's are going to have =
the
fs consistent and will have the superblock in the same location. Whether you
wish to move this around at a later point in time or not is really pretty
irrelevant. Realistically, the majority of people who want to read/write the
VMU's are going to be those who want to modify existing saved game data.. so
repositioning the superblock is pretty much useless. And for most "sane"
filesystems, the superblock will reside at the beginning of the volume .. so
repositioning this stuff is still useless.

> > 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 tol=
d you a
> > good while ago that a driver was already in place and was merely in nee=
d of a
> > bit of fixing up.. reinventing the wheel is a completely useless activi=
ty
> > here).
>=20
> Again, I might misunderstand how your driver is supposed to work, but
> it seems to me that your driver will only be able to write 50-60 bytes per
> second to the vmu. If that is the case, a new wheel might be a good idea.
> (Since it (a) writes one byte at a time and (b) a vmu needs a small timeo=
ut
>  after each write)
>=20
Again, you seem to misunderstand things like 16 and 32bit writes being
supported. Since this has been stated about a dozen times by now, I'll pres=
ume
you've caught on to the fact that you can indeed do non-byte access to the
device and that you can indeed push more than 50-60 bytes per second to the
VMU. As far as the timeout is concerned.. that's a pretty useless point, and
can easily be pushed into the existing MTD driver.

If you think you need a new wheel to accomplish this, then go right ahead..
you're entitled to spend as much time heading down the wrong path as you li=
ke.
Though it would be nice if you were doing something that would benefit
everyone (ie, VMU fs) instead of trying to reinvent those things that don't
need reinventing.

Regards,

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