OSDev.org

NickJohnson wrote:What language are you using to do all this, and what exactly is the implementation of a "package"?

NickJohnson wrote:Okay, so by "interface" you effectively mean header file with prototypes?

Since you're using C, this seems like a job for structures filled with function pointers.

typedef struct hw_generic_ata_Ata hw_generic_ata_Ata;
struct hw_generic_ata_Ata{

  hw_generic_ata_DiagnosticCode (*executeDriveDiagnostic)(
    hw_generic_ata_Ata* this);

  // TODO: Consider returning a string
  void (*getFirmwareRevision)(hw_generic_ata_Ata* this, char* str);

  // TODO: Consider returning a string
  void (*getModelNumber)(hw_generic_ata_Ata* this, char* str);

  // TODO: Consider returning a string
  void (*getSerialNumber)(hw_generic_ata_Ata* this, char* str);

  // TODO: Consider returning the data struct
  bool (*identifyDrive)(
    struct hw_generic_ata_Ata* this,
    struct hw_generic_ata_IdentifyDriveData* identifyDriveData);

  bool (*isDmaSupported)( struct hw_generic_ata_Ata* this );
  bool (*isLbaSupported)( struct hw_generic_ata_Ata* this );

  // TODO: Use a Buffer-like object instead of uint8*
  void (*readSectorChs)( hw_generic_ata_Ata* this,
    struct hw_generic_ata_Chs* sectorAddress, uint16* data); 

  void (*readSectorLba)( hw_generic_ata_Ata* this, uint32 lba, uint16* data); 
};

NickJohnson wrote:It seems like instead of a separate adapter for each driver, you could just have each driver that implements an interface contain that interface structure within it's own. For example, struct hw_generic_ata_Ata could contain a pointer to a struct kernel_io_block_BlockDevice, which could be passed around when only the block device interface is needed.

• The port driver (i.e. the "ATA Port driver") which is responsible for handling the general ATA portions of the interface, and translating from block device operations to said interface
• The miniport driver (i.e. the "ICH7 UDMA ATA Driver") which is responsible for talking to the actual hardware

RaffoPazzo wrote:Already thought about that and discarded because this would mean to pollute the hw_generic_ata_Ata interface by something not defined in the ATA specification. Actually, providing hw_generic_ata_BlockDeviceAdpater results in polluting the hw_generic_ata package, bad too...

Owen wrote:As an aside: Your interfaces appear synchronous; this is very poor design for a driver interface (where most devices are asynchronous anyway)

berkus wrote:Shouldn't interface reflect a "concept" e.g. BlockDevice and ATA being just an implementation detail at a different level?

Your clients wouldn't care much if they speak to an ATA device or SCSI device as long as they can get their blocks in and out.

NickJohnson wrote: I understand the idea of having the interface contain all of the functions in the spec, but having it so something is in the interface if and only if it is in the spec seems like overkill, especially because the previous suggestion would be an easy and effective fix. You also might run into trouble with your system if you try and write a driver for something with multiple conflicting specs or poor documentation.

eddyb wrote:Why does it look like you're trying to do object-oriented interface in... C?
Have you considered taking advantage of C++'s classes (and other features)? Inheritance, virtual inheritance, templates, all that good stuff.
(Just pointing out that the complication is in the implementation, the idea is pretty good )

RaffoPazzo wrote:

eddyb wrote:Why does it look like you're trying to do object-oriented interface in... C?
Have you considered taking advantage of C++'s classes (and other features)? Inheritance, virtual inheritance, templates, all that good stuff.
(Just pointing out that the complication is in the implementation, the idea is pretty good )

Simply because it is right what i'm doing
Already considered using C++ and discarded because of too many hidden stuff I wouldn't like facing with (e.g. vtable, operators, name mangling, exception handling performances and templates as well, this last one in C++ are not so good as they seems). My opinion is quite simple: C is basically portable assembly. Using it for object-oriented development is just a matter of writing code properly, which is easily aviodable using the proper tools.

eddyb wrote: I'm not even going to let trolls get this one...
Vtable is not your problem. Operators, not your problem. Name mangling, not your problem. Exception handling, not your problem (can be disabled). Templates rule and don't require any support code (just use them, they're like super-powerful macros).
You only need a few special functions and you're done (see cppsupport.cc from pedigree. this is with highlighting and without debugging stuff).
And yes, writing messy C code can be avoided using the proper tools, which why I mentioned C++. Please don't make me start ranting about GNU C.

RaffoPazzo wrote:

eddyb wrote: I'm not even going to let trolls get this one...
Vtable is not your problem. Operators, not your problem. Name mangling, not your problem. Exception handling, not your problem (can be disabled). Templates rule and don't require any support code (just use them, they're like super-powerful macros).
You only need a few special functions and you're done (see C++ on the wiki).
And yes, writing messy C code can be avoided using the proper tools, which why I mentioned C++. Please don't make me start ranting about GNU C.

You asked me if I considered using C++ and I just replied you that I had and what was my conclusions. If you think that C++ is applicable for your OS development then use it, no one cares.
Don't try to teach people what they already deeply know and don't point people you don't know using terms like trolls, they could teach you things which you would never imagine the existance. Moreover, no one asked your impressions about GNU C.

You have totally ingored the only question discussed in this topic. Your information contribute is still null. Be productive.

RaffoPazzo wrote:

Code: Select all

typedef struct hw_generic_ata_Ata hw_generic_ata_Ata;
struct hw_generic_ata_Ata{

  hw_generic_ata_DiagnosticCode (*executeDriveDiagnostic)(
    hw_generic_ata_Ata* this);

  // TODO: Consider returning a string
  void (*getFirmwareRevision)(hw_generic_ata_Ata* this, char* str);

  // TODO: Consider returning a string
  void (*getModelNumber)(hw_generic_ata_Ata* this, char* str);

  // TODO: Consider returning a string
  void (*getSerialNumber)(hw_generic_ata_Ata* this, char* str);

  // TODO: Consider returning the data struct
  bool (*identifyDrive)(
    struct hw_generic_ata_Ata* this,
    struct hw_generic_ata_IdentifyDriveData* identifyDriveData);

  bool (*isDmaSupported)( struct hw_generic_ata_Ata* this );
  bool (*isLbaSupported)( struct hw_generic_ata_Ata* this );

  // TODO: Use a Buffer-like object instead of uint8*
  void (*readSectorChs)( hw_generic_ata_Ata* this,
    struct hw_generic_ata_Chs* sectorAddress, uint16* data); 

  void (*readSectorLba)( hw_generic_ata_Ata* this, uint32 lba, uint16* data); 
};