Re: MMAPPED disk package

["Anthony Tonizzo" <atonizzo at gmail dot com>]

Gentlemen:

Here is my next stab at the mmapped package. With the exception of the 8/16
bit code rearrangement, I have implemented pretty much everything that Jonathan
suggested in his previous e-mail, the 8/16 bit code was also done, but at the
end of the story refefinition of typedefs, pointers and function was
so intricate
that I could see no immediate benefit to it versus the current clean
(if somewhat
verbose) implementation. But these are details: We'll figure them out. In the
meantime, I would point you to the "meat" of the code, the implementation
of another one of your suggestions, which, after it was done, raised
more questions
than it solved. From Jonathan's last e-mail:

> The initialisation doesn't seem quite right. It seems to me that the
> CF_DISK_INSTANCE macro should be defined in an exported header file, and
> then the relevant platform HAL should instantiate devices using that macro.
...
> This also gives the possibility, in the HAL, of disabling a CF interface by
> CDL. This could be important, e.g. on powerpc MBX, so that you can add
> CYGPKG_IO_DISK to your config, but not get potentially unnecessary CF
> support. You might be wanting support for SPI dataflash, not CF so there
> needs to be a way to disable it.

This was done. You can see the way it was implmented in the CDL file
for the package, with the new define_proc line which points to the
cyg/io/mmapped_disk.inl file. Having said that, here are a few musings on the
subject.

I appreciate clearly the advantages of having the platform hal enable the
peripherals that I want to use. Case in point, an MPC8xx processor could
support two disks using my package (because said processor has
two independent PCMCIA ports) but the MBX platform in particular can
have only one, for the simple reason that only one of the ports is wired to a
connector. This brings home the concept that from a logical standpoint
the platform HAL is where most of the peripherals should get instantiated.
Only problem is that that is not the way it is done now, and changing it
is no trivial undertaking because it likely involves changing every single
HAL supported by eCos. Bart must have realized that himself, because when
he recently wrote the MMC package, also in the devs/disk directory, he wrote
in a comment:

// And finally the data structures that define this disk. Some of this
// should be moved into an exported header file so that applications can
// define additional disks.

But then he ended up doing it the "usual" way, exactly the way it is implemented
in the IDE and was in my package. I want what makes sense for the OS, but
if I do it for my package, then we have to do it for all other disk packages
as well, if nothing else for the sake of consistency.

But then where does this stop? The platform HAL would also be the ideal place
to instantiate, say, one or more Ethernet ports. And how about serial ports?
Processors such as the MPC8xx have a number of both, and depending on
the particular platform, only some of those are accessible, and thus the
platform hal is where these devices should _really_ be instantiated. Of course
you realize how slippery this slope has suddenly become.

For now, of all the disks implementation (IDE, MMC, V85x and mine) only mine
defers the instantiation to the platform HAL. I find this somewhat confusing
to the user and surely in need of a clear direction for the future.

> and dev_disk_mmapped.c no longer forced into libextras.a (instead the above
> instantiating HAL file would be instead).

I have to plead ignorance here. I copied the CDL from Savin's V85x package
and never asked myself why the file is forced into libextras.a. I am not even
aware of implications, advantages and disadvantages. However, now the code
compiles in libtarget.a

Tony

Attachment: diff.txt.gz
Description: GNU Zip compressed data