Patches to add basic support for the Suunto EON Steel

[Jef Driesen]

On 03-11-14 17:31, Linus Torvalds wrote:
>
> On Nov 3, 2014 8:12 AM, "Jef Driesen" <jef at libdivecomputer.org
> <mailto:jef at libdivecomputer.org>> wrote:
>  >
>  > Also, my patch with the casts was merely to indicate where the problems were,
> and not supposed to be applied as is. Ideally I would rather see the root
> problem "fixed" instead of fixing the symptoms.
>
> But the root problem is that you're compiler is wrong. Anything else is just
> papering over that issue. The code is C, and better idiomatic C at that.
>
> How the heck can I fix the "root" problem that you aren't even using a proper C
> compiler, and then make up your own rules about what code is supposed to look
> like, but those rules aren't even the patches you send me?
>
> Jef, that's just crazy. If you have random personal rules that don't even make
> sense in the context of the language, then make those changes yourself. Don't
> make me have to guess what your are thinking. I don't have ESP and unlike you I
> don't have a broken  compiler, or think that I should care about the
> known-broken warning messages from it.
>
> So now you tell me that the patch y patch sent me want even what you wanted.
> Really, I'm not willing to play some clown to your crazy rules.
>
> Dirk, please take over. I'm done.

Well, I can't really do much about the lack of C99 support in the msvc compiler. 
I'm the first to admit that compiling as C++ is one ugly hack. But I'm willing 
to pay that price because msvc support matters for many Windows developers (and 
no, I'm not one of those). Windows happens to be one of the officially supported 
platforms. It's fine if *you* don't care about that, but libdivecomputer does... 
and thus every new backend too.

Anyway, I was just trying to be helpful and point out where the issues with msvc 
where, in order to get the eonsteel backend ready as soon as possible. I don't 
think I ever said you have to fix those issues all by yourself. If you told me 
"Hey Jef, Here's what I have already. It works fine on Linux, but I don't want 
to deal with all those crazy msvc workarounds. Just take the code and do 
whatever you need to do to get it working with msvc." or something like that, 
then that would have been fine too. Then me, or someone else, can take care of 
that. It's a public mailinglist after all. Granted, it would likely take a bit 
longer before I would be able to work on that.

But... and correct me if I wrong, I had the impression that we wanted to have 
this ready as fast as possible. So I did an effort to provide feedback as quick 
as possible and try to clearly explain the kind of changes I wanted. And that 
included those extra msvc tricks. So I just fired up my Windows VM to check what 
the msvc compiler didn't like and send you a quick "patch". Maybe I should have 
been a bit more explicit there.


Do you really consider the changes I asked unreasonable? The only changes I 
really insist on are proper integration into the existing infrastructure, and a 
working build on all supported platforms. That doesn't sound crazy to me. And 
here I'm not even talking about those pointer casts (which are strictly speaking 
also required for proper C code, except for void pointers).

A small analogy. What would you say if I submit a linux kernel patch and say 
"Hey, I didn't like the existing printk function, so I just used my own custom 
logging function." Won't your response be something along the lines of "Hey, 
whether you like it or not, but the kernel uses printk, so please use that."? 
Because that's what I have been asking.


So how do we proceed next? Do I take your code and integrate the logging and 
msvc stuff myself?

Jef