[CFR] mge driver / elf reloc

[Warner Losh]

On Aug 8, 2014, at 10:14 PM, John-Mark Gurney <jmg at funkthat.com> wrote:

> Ian Lepore wrote this message on Fri, Aug 08, 2014 at 16:15 -0600:
>> On Mon, 2014-07-21 at 10:40 +0200, Fabien Thomas wrote:
>>> On 21 Jul 2014, at 01:10, John-Mark Gurney <jmg at funkthat.com> wrote:
>>> 
>>>> Tim Kientzle wrote this message on Sun, Jul 20, 2014 at 15:25 -0700:
>>>>> 
>>>>> On Jul 20, 2014, at 3:05 PM, John-Mark Gurney <jmg at funkthat.com> wrote:
>>>>> 
>>>>>> Ian Lepore wrote this message on Sat, Jul 19, 2014 at 16:54 -0600:
>>>>>>> Sorry to take so long to reply to this, I'm trying to get caught up.  I
>>>>>>> see you've already committed the mge fixes.  I think the ELF alignment
>>>>>>> fix looks good and should also be committed.
>>>>>> 
>>>>>> So, re the elf alignment...
>>>>>> 
>>>>>> I think we should get a set of macros that handle load/stores to/from
>>>>>> unaligned addresses that are transparent to the caller....  I need
>>>>>> these for some other code I'm writing... 
>>>>>> 
>>>>>> I thought Open/Net had these available, but I can't seem to find them
>>>>>> right now...
>>>>> 
>>>>> $ man 9 byteorder
>>>>> 
>>>>> is most of what you want, lacking only some aliases to pick
>>>>> the correct macro for native byte order.
>>>> 
>>>> Um, those doesn't help if you want native endian order...
>>>> 
>>>> Also, only the enc/dec functions are documented to work on non-aligned
>>>> address, so that doesn't help in most cases...
>>> 
>>> Yes, having an API to read unaligned pointer is better than than using local fix like in the patch.
>>> Tell me if you add one and I can adapt the patch.
>>> 
>>> Fabien
>>> 
>> 
>> So can we just get this patch committed as-is, and then maybe convert it
>> later to the much-desired "something better" that this discussion
>> deteriorated into?
>> 
>> http://people.freebsd.org/~fabient/ARM/patch-arm_elf_alignfix
>> 
>> If you've ever wondered whether there are real costs to bikeshedding,
>> this is an example of such.  This relocation patch is the fix to the
> 
> Yes and no...  Yes, this delayed it, but replys on improvement were
> given (Warner's) and then no action was taken...
> 
> I want us to continue to take the better way than the quickest way...
> 
>> kernel module loading problem HPS has been having, and who knows how
>> much time he had to waste debugging it.  I know I spent 4 hours on it
>> today before discovering that the problem was known and fixed, only the
>> fix isn't committed yet.
> 
> I agree w/ Warner that the conditional should be removed and we always
> call load_ptr/store_ptr...

The feedback was given quickly, but no reply was forthcoming. Criticizing the feedback
seems rather out of line.

I’ll commit something this weekend, but honestly the feedback wasn’t a bikeshed by
any stretch of the imagination.

Warner
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 842 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.freebsd.org/pipermail/freebsd-arm/attachments/20140809/cbb835e3/attachment.sig>