1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
|
[[!meta copyright="Copyright © 2012, 2013, 2014 Free Software Foundation,
Inc."]]
[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable
id="license" text="Permission is granted to copy, distribute and/or modify this
document under the terms of the GNU Free Documentation License, Version 1.2 or
any later version published by the Free Software Foundation; with no Invariant
Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license
is included in the section entitled [[GNU Free Documentation
License|/fdl]]."]]"""]]
Things to consider regarding *versioning*.
The provider and user of any interface need to agree about how to interpret the
data being exchanged. Internal-only interfaces can be changed easily, because
you can change the provider and user at the same time. Interfaces that are
exposed externally require more attention, for obvious reasons. To *change*
interfaces means to either remove, or add, or modify an existing interface.
Modify basically means to remove and then re-add a variant, re-using the former
name/identifier.
[[!toc]]
# [[RPC]]s
## [[microkernel/mach/message/msgh_id]]
# Shared Libraries
* [[!wikipedia soname]]
* ELF symbol versioning
* [[!wikipedia "GNU Libtool"]]
## Hurd
Transition to "normal" ELF symbol versioning/libtool?
For all libraries, the SONAME is currently set to *0.3*. [[!message-id
desc="Not changed" "87ob7cxbu6.fsf@kepler.schwinge.homeip.net"]] when doing the
[[Hurd 0.5 release|news/2013-09-27]].
## glibc
Bump the glibc SONAME to some point, or can do everything with symbol
versioning?
There are some comments in the sources, for example `hurd/geteuids.c`: `XXX
Remove this alias when we bump the libc soname.`
### IRC, freenode, #hurd, 2012-12-14
[[!tag open_issue_glibc open_issue_libpthread]]
In context of [[service_solahart_jakarta_selatan__082122541663/packaging_libpthread]]/[[service_solahart_jakarta_selatan__082122541663/libpthread]].
<pinotree> once libc is switched internally from cthreads to pthreads (thus
breaking its BC), may be worth cleanup the hurd-specific exported symbols
<tschwinge> pinotree: Yes. If you already have ideas about what to clean
up, feel free to add a new page or a section on open_issues/glibc.
<pochu> we're gonna break backwards compatibility in glibc on hurd? that
could be the perfect moment to fix the /dev/fd/N problem without adding
new RPCs, though we'd probably have to break backwards-compatibility in
the exec server IIRC...
[[service_solahart_jakarta_selatan__082122541663/glibc#execve_relative_paths]].
### `time_t` -- Unix Epoch vs. 2038
#### IRC, freenode, #hurd, 2013-12-12
<azeem> because it gets discussed in #debian-devel for the Linux i386
architecture right now: what's the deal with hurd-i386 and the 32bit
epoch overflow in 2038?
<braunr> what do you mean ?
<azeem> braunr: http://lwn.net/Articles/563285/
<braunr> ok but what do you mean ?
<braunr> i don't think there is anything special with the hurd about that
<azeem> well, time_t is 64bit on amd64 AIUI
<braunr> it's a signed long
<azeem> so maybe the Hurd guys were clever from the start
<azeem> k, k
<braunr> our big advantage is that we can afford to break things a little
without too much trouble
<braunr> in a system at work, we use unsigned 32-bit words
<braunr> which overflows in 2106
<braunr> and we already include funny comments that predict our successors,
if any, will probably fail to deal with the problem until short before
the overflow :>
<azeem> luckily, no nuclear reactors are running the Hurd sofar
<braunr> i wonder how the problem will be dealt with though
<braunr> ah, openbsd decided to break their abi
<azeem> yeah
<braunr> that's probably the simplest solution
<azeem> "just recompile"
<braunr> and they can afford it too
<azeem> yeah
<braunr> good to see people actually worry about it
<azeem> I guess people are getting worried about where Linux embedded is
being put into
<braunr> they're right about that
<azeem> "Please, don't fix the 2038 year issue. I also want to have some
job security :)"
<braunr> haha
|
