Yes, but is this bad considering there would be info loss ANY time the
table overflowed? Again, the operation succeeds with an error message.
I *could* avoid this - by reserving 1 region entry for release requests,
or checking for a free region before doing anything.
>> int request_hw_region( uint first, uint num, const char *name, int type );
>> int release_hw_region( uint first, uint num, int type );
>> - Returns 0 on success, and either -EINVAL or -EBUSY on failure.
>> - It is important that no attempt be made to release a region that has not
>> been successfully requested.
>
>I think it'd be a good idea to include with the "name" (which says what
>it is being requested (or what it is requested for)) is "who" ... who is
>making the request? Release of a requested region must match on "who" is
>releasing ...
That was exactly my idea, but I've not come up with a satisfactory 'who'.
Any ideas?
>> hwres_t * request_hw_resources( hwres_t *table, const char *name );
>> hwres_t * release_hw_resources( hwres_t *table );
>> - Both return a pointer to the first HWRES_END entry in the table (required).
>> - The 'failed' member of hdwres_t is the return code for each operation.
>> - The 'failed' member of first HWRES_END entry applies to all operations.
>> - Entries that have a non-zero 'failed' member are ignored on release.
>
>Does it mean the function allocates _ALL_ requested regions in a single
>call and if any request fails, they all fail? Certainly supports atomicity
>requirements.
It means that any SINGLE request in the table can fail - this does not
stop any following request. The SINGLE request status is returned in the
'failed' member of that entry. If ANY of the requests failed, the
'failed' member of the HWRES_END entry will show it.
Make sense? I'll try to clear this part up.
-- Andrew E. Mileski --
-------------------------------------------------------
Located in Canada's Capital: Ottawa! (EST)
mailto:dmtech@magi.com http://www.magi.com/~dmtech/