Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Message-ID: <ca17f815-5779-d37c-e3f8-2a6c2983fe45@selasky.org>
Date:   Tue, 11 Apr 2023 17:33:01 +0200
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:102.0) Gecko/20100101
 Thunderbird/102.9.1
Subject: Re: [PATCH 0/6] Initial Rust V4L2 support
Content-Language: en-US
To:     Miguel Ojeda <miguel.ojeda.sandonis@gmail.com>
Cc:     Daniel Almeida <daniel.almeida@collabora.com>, wedsonaf@gmail.com,
        ojeda@kernel.org, mchehab@kernel.org, hverkuil@xs4all.nl,
        rust-for-linux@vger.kernel.org, linux-kernel@vger.kernel.org,
        linux-media@vger.kernel.org, kernel@collabora.com
References: <20230406215615.122099-1-daniel.almeida@collabora.com>
 <441a96cb-7dd1-0885-df64-933ebdb55e9e@selasky.org>
 <0ec4becd05c49e8f0bf214fbd62208ea67c2b4c3.camel@collabora.com>
 <6fc0a0c6-a7c9-5350-9b9e-1ea9dab568d0@selasky.org>
 <CANiq72m812+L6dc4Qs2wUXW85eBQwgrjWYYKc1MSsqN5AG_sFw@mail.gmail.com>
 <9f896097-8410-4d09-b614-6e792b2160f4@selasky.org>
 <CANiq72mv2uYe1x6cy4zUq8XHhAZcYYpt6hVXMG4yQZeqw1kY7Q@mail.gmail.com>
 <1d50d25c-e64b-01f4-029f-8b40b46848fd@selasky.org>
 <CANiq72mbM+WBcvj1TwU2u9kLz=EucLhLR-a5nzZEDa7VJ0s2_A@mail.gmail.com>
From:   Hans Petter Selasky <hps@selasky.org>
In-Reply-To: <CANiq72mbM+WBcvj1TwU2u9kLz=EucLhLR-a5nzZEDa7VJ0s2_A@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Precedence: bulk

On 4/11/23 16:19, Miguel Ojeda wrote:
> On Tue, Apr 11, 2023 at 3:15 PM Hans Petter Selasky <hps@selasky.org> wrote:
>>
>> If you cannot build a new toolchain without a new kernel.
> 

Hi,

> Why not?

To me it is very simple:

Look at this:

-#define FE_GET_PROPERTY                   _IOR('o', 83, struct 
dtv_properties)
+#define FE_GET_PROPERTY                   _IOW('o', 83, struct 
dtv_properties)
+#define FE_GET_PROPERTY_OLD       _IOR('o', 83, struct dtv_properties)

The FE_GET_PROPERTY IOCTL definition is incorrectly specified as reading 
data. While it is actually writing data. When will this be fixed in 
Linux - I think never. That's just the way both Linux and GIT works, 
unfortunately, though that's another discussion. You can put stuff in, 
but you can't easily get stuff out, without it having consequences.

Similarly rustc may depend on an incorrectly specified ioctl() 
definition, also via other libraries and static linking, that just have 
to stay incorrectly defined, because it was initially incorrectly defined.

Daniel, please explain why the few lines of chunk above (and there are 
some more) cannot be upstreamed into Linux?

> 
>> Then you are stuck forever to build a new toolchain and kernel? Do you
>> agree?
> 
> No, I don't agree, because I don't understand why you cannot build the
> new toolchain in the old kernel, or use a pre-built toolchain for that
> matter (whether built by you or by somebody else).
> 
>> Or you can say, someone else needs to deal with it, but then you have a
>> single point of failure.
> 
> No, you could build your own toolchain and save it somewhere, if you
> don't want to rely on a build from somebody else.

I'm trying to explain something difficult. And I'm OK that you neither 
understand nor agree about my viewpoint. See my replies above.

--HPS