Em Sat, 6 Feb 2021 11:18:15 +0100
Hans Verkuil escreveu:
> >> Yes, driver "version" means nothing, so functionality is the correct way
> >> to handle this.
> >>
> >> Any chance you all can just drop the kernel version stuff and just
> >> report a static number that never goes up to allow people
On 06/02/2021 10:48, Mauro Carvalho Chehab wrote:
> Em Sat, 6 Feb 2021 10:29:10 +0100
> Greg Kroah-Hartman escreveu:
>
>> On Sat, Feb 06, 2021 at 10:24:02AM +0100, Mauro Carvalho Chehab wrote:
>>> Em Sat, 6 Feb 2021 08:20:45 +0100
>>> Greg Kroah-Hartman escreveu:
>>>
On Fri, Feb 05,
Em Sat, 6 Feb 2021 10:29:10 +0100
Greg Kroah-Hartman escreveu:
> On Sat, Feb 06, 2021 at 10:24:02AM +0100, Mauro Carvalho Chehab wrote:
> > Em Sat, 6 Feb 2021 08:20:45 +0100
> > Greg Kroah-Hartman escreveu:
> >
> > > On Fri, Feb 05, 2021 at 07:11:05PM +0100, Mauro Carvalho Chehab wrote:
>
On Sat, Feb 06, 2021 at 10:24:02AM +0100, Mauro Carvalho Chehab wrote:
> Em Sat, 6 Feb 2021 08:20:45 +0100
> Greg Kroah-Hartman escreveu:
>
> > On Fri, Feb 05, 2021 at 07:11:05PM +0100, Mauro Carvalho Chehab wrote:
> > > Em Fri, 5 Feb 2021 12:31:05 -0500
> > > Tony Battersby escreveu:
> > >
Em Sat, 6 Feb 2021 08:20:45 +0100
Greg Kroah-Hartman escreveu:
> On Fri, Feb 05, 2021 at 07:11:05PM +0100, Mauro Carvalho Chehab wrote:
> > Em Fri, 5 Feb 2021 12:31:05 -0500
> > Tony Battersby escreveu:
> >
> > > On 2/4/21 6:00 AM, Jiri Slaby wrote:
> > > > Agreed. But currently, sublevel
On Fri, Feb 05, 2021 at 07:44:12PM +0100, Pavel Machek wrote:
> Hi!
>
> > > > Ugh, I thought this was an internal representation, not an external one
> > > > :(
> > > >
> > > > > It might work somewhere, but there are a lot of (X * 65536 + Y * 256
> > > > > + Z)
> > > > > assumptions all around
On Fri, Feb 05, 2021 at 12:31:05PM -0500, Tony Battersby wrote:
> On 2/4/21 6:00 AM, Jiri Slaby wrote:
> > Agreed. But currently, sublevel won't "wrap", it will "overflow" to
> > patchlevel. And that might be a problem. So we might need to update the
> > header generation using e.g. "sublevel &
On Fri, Feb 05, 2021 at 07:11:05PM +0100, Mauro Carvalho Chehab wrote:
> Em Fri, 5 Feb 2021 12:31:05 -0500
> Tony Battersby escreveu:
>
> > On 2/4/21 6:00 AM, Jiri Slaby wrote:
> > > Agreed. But currently, sublevel won't "wrap", it will "overflow" to
> > > patchlevel. And that might be a
Em Fri, 5 Feb 2021 12:31:05 -0500
Tony Battersby escreveu:
> On 2/4/21 6:00 AM, Jiri Slaby wrote:
> > Agreed. But currently, sublevel won't "wrap", it will "overflow" to
> > patchlevel. And that might be a problem. So we might need to update the
> > header generation using e.g. "sublevel &
Hi!
> > > Ugh, I thought this was an internal representation, not an external one
> > > :(
> > >
> > > > It might work somewhere, but there are a lot of (X * 65536 + Y * 256 +
> > > > Z)
> > > > assumptions all around the world. So this doesn't look like a good idea.
> > >
> > > Ok, so what
On 2/4/21 6:00 AM, Jiri Slaby wrote:
> Agreed. But currently, sublevel won't "wrap", it will "overflow" to
> patchlevel. And that might be a problem. So we might need to update the
> header generation using e.g. "sublevel & 0xff" (wrap around) or
> "sublevel > 255 : 255 : sublevel" (be
On Fri, Feb 05, 2021 at 10:06:59AM +0100, Pavel Machek wrote:
> On Thu 2021-02-04 09:51:03, Greg Kroah-Hartman wrote:
> > On Thu, Feb 04, 2021 at 08:26:04AM +0100, Jiri Slaby wrote:
> > > On 04. 02. 21, 7:20, Greg Kroah-Hartman wrote:
> > > > On Thu, Feb 04, 2021 at 05:59:42AM +, Jari Ruusu
On Thu 2021-02-04 09:51:03, Greg Kroah-Hartman wrote:
> On Thu, Feb 04, 2021 at 08:26:04AM +0100, Jiri Slaby wrote:
> > On 04. 02. 21, 7:20, Greg Kroah-Hartman wrote:
> > > On Thu, Feb 04, 2021 at 05:59:42AM +, Jari Ruusu wrote:
> > > > Greg,
> > > > I hope that your linux kernel release
On Thu, Feb 04, 2021 at 09:19:33PM +0100, Christoph Biedl wrote:
> David Laight wrote...
>
> > A full wrap might catch checks for less than (say) 4.4.2 which
> > might be present to avoid very early versions.
> > So sticking at 255 or wrapping onto (say) 128 to 255 might be better.
>
> Hitting
David Laight wrote...
> A full wrap might catch checks for less than (say) 4.4.2 which
> might be present to avoid very early versions.
> So sticking at 255 or wrapping onto (say) 128 to 255 might be better.
Hitting such version checks still might happen, though.
Also, any wrapping introduces a
On Thu, Feb 04, 2021 at 04:28:19PM +, David Laight wrote:
> From: Jiri Slaby
> > Sent: 04 February 2021 11:01
> >
> > On 04. 02. 21, 9:51, Greg Kroah-Hartman wrote:
> > >> It might work somewhere, but there are a lot of (X * 65536 + Y * 256 + Z)
> > >> assumptions all around the world. So
From: Jiri Slaby
> Sent: 04 February 2021 11:01
>
> On 04. 02. 21, 9:51, Greg Kroah-Hartman wrote:
> >> It might work somewhere, but there are a lot of (X * 65536 + Y * 256 + Z)
> >> assumptions all around the world. So this doesn't look like a good idea.
> >
> > Ok, so what happens if we "wrap"?
On 04. 02. 21, 9:51, Greg Kroah-Hartman wrote:
It might work somewhere, but there are a lot of (X * 65536 + Y * 256 + Z)
assumptions all around the world. So this doesn't look like a good idea.
Ok, so what happens if we "wrap"? What will break with that? At first
glance, I can't see anything
On Thu, Feb 04, 2021 at 08:26:04AM +0100, Jiri Slaby wrote:
> On 04. 02. 21, 7:20, Greg Kroah-Hartman wrote:
> > On Thu, Feb 04, 2021 at 05:59:42AM +, Jari Ruusu wrote:
> > > Greg,
> > > I hope that your linux kernel release scripts are
> > > implemented in a way that understands that
On 04. 02. 21, 7:20, Greg Kroah-Hartman wrote:
On Thu, Feb 04, 2021 at 05:59:42AM +, Jari Ruusu wrote:
Greg,
I hope that your linux kernel release scripts are
implemented in a way that understands that PATCHLEVEL= and
SUBLEVEL= numbers in top-level linux Makefile are encoded
as 8-bit
On Thu, Feb 04, 2021 at 05:59:42AM +, Jari Ruusu wrote:
> Greg,
> I hope that your linux kernel release scripts are
> implemented in a way that understands that PATCHLEVEL= and
> SUBLEVEL= numbers in top-level linux Makefile are encoded
> as 8-bit numbers for LINUX_VERSION_CODE and
>
Greg,
I hope that your linux kernel release scripts are
implemented in a way that understands that PATCHLEVEL= and
SUBLEVEL= numbers in top-level linux Makefile are encoded
as 8-bit numbers for LINUX_VERSION_CODE and
KERNEL_VERSION() macros, and must stay in range 0...255.
These 8-bit limits are
22 matches
Mail list logo
