| 1 |
On Wednesday, January 10, 2018, Benda Xu <heroxbd@g.o> wrote: |
| 2 |
> Hi MJ, |
| 3 |
> |
| 4 |
> "M. J. Everitt" <m.j.everitt@×××.org> writes: |
| 5 |
> |
| 6 |
>> Not entirely as a #gentoo-nit-pick .. I'm slightly unclear on the |
| 7 |
>> different between 2.6.16+ and 2.6.32+ .. should this potentially be |
| 8 |
>> 2.16.16-32 perhaps [2.6.16~32 even] or is this more obvious only to me, |
| 9 |
>> and more confusing to others.... |
| 10 |
> |
| 11 |
> 2.6.16+ means that it can be used in any cases when the kernel is newer |
| 12 |
> than 2.6.16. For example, you can use it on linux-4.14, just with |
| 13 |
> unnecessary backward compatibility code. |
| 14 |
> |
| 15 |
> Besides, with the newest profile, kernel-3.2+, the ending kernel version |
| 16 |
> is not known. We will have to rename it when glibc jumps if the profile |
| 17 |
> is named with a version range. |
| 18 |
> |
| 19 |
|
| 20 |
I don't want to just comment on naming, but: |
| 21 |
|
| 22 |
It might be more natural to go the other way. Split profiles off based on |
| 23 |
version when breakage occurs, and otherwise do not reference a specific |
| 24 |
version. |
| 25 |
|
| 26 |
Then, the name indicates the most recent kernel supported by the profile. |
| 27 |
So remove the plus and (I think) shift all of the names "forward." |
| 28 |
|
| 29 |
So 2.6.16 becomes 2.6.32, and 2.6.32 becomes the next profile's name. |
| 30 |
|
| 31 |
This seems more natural but does change the semantics of the name. Would |
| 32 |
that be a problem? Is it expected people would want to use the profiles |
| 33 |
with compatibility features on newer kernels? |
| 34 |
|
| 35 |
This setup would prevent having to verify that old code works on new |
| 36 |
systems, which is implied to be supported.by the + naming (again, not sure |
| 37 |
if it matters). |
| 38 |
|
| 39 |
Cheers, |
| 40 |
R0b0t1 |
Archives