Hi Roman!
* the detect_native_features() dissapeared effectively
making a NATFEAT
capable kernel not operating on normal atari HW.
Why? What happens?
Well, in nf_init() it uses the nf_get_id() instruction which
is illegal on a normal m68k. Or am I missing something? Is that
trapped during the initialization?
* The nfeth.c file now doesn't use any wrappers around the nf_call()
executions. I am not completely sure if this should be
adopted as the
default way to deal with natfeats as the nf_call()
arguments are supposed
to be all 4 byte long (that is the definition of the
interface) whereas
if left as is one needs to pay a lot of attention to all
parameter sizes
and necessary casting where appropriate.
The 4 byte alignment is the default anyway when pushing
arguments on the stack, so you only need to take care of 64bit
values, which need special handling anyway.
Hmm, I remember having a lot of problems there, but that might
have been caused by -mshort usage in the FreeMiNT world...
Anyway, so if I say have a 'short' variable with a value of 0xabcd
and I use it as an argument for an ellipsis function (the nf_call()
in our case) it would store it like '0xXXXXabcd' on the stack.
Is that upper XXXX guaranteed to be 0000? Or do I need to cast
the value to be 4 byte wide to make it 0000? I am sorry if these
are obvious things for gcc insiders, but I just seem to remember
seeing interesting problems related to this and I am almost positive
that this wasn't just the -mshort case.
I'm not completely opposed to wrappers, but I think there are
overkill for simple callers and/or single users. The main reason
I killed the wrappers is that they practically splitted the driver
in two parts and added an extra layer, so I just replaced the
wrappers with direct calls and just never bothered with them again.
There are also some calls in the NF interfaces which would be nice
to wrap with fewer arguments for the Linux kernel purposes. I'd be
for inline functions that would wrap them.
Best Regards
Standa
-
To unsubscribe from this list: send the line "unsubscribe linux-m68k" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
