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 [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
