On Thu, Nov 13, 2014 at 03:29:48PM +0900, Masao Uebayashi wrote:
> On Wed, Nov 12, 2014 at 2:53 AM, Taylor R Campbell
> wrote:
> >Date: Tue, 11 Nov 2014 17:42:51 +
> >From: Antti Kantee
> >
> >2: init_main ordering
> >
> >I think that "code reading" is an absolute req
(snip)
How about spending your energy to investigate real dependencies, for example:
http://nxr.netbsd.org/xref/src/sys/kern/init_main.c#559
Does pax depend on veriexec?
Does ipsec depend on pax?
On Wed, Nov 12, 2014 at 2:42 AM, Antti Kantee wrote:
> There are two separate issues here:
>
> 1: link sets vs. ctors
>
> They are exactly the same thing in slightly different clothing. Mental
> exercise: define link_set_ctor and run those in kernel bootstrap when you'd
> run __attribute_
On Wed, Nov 12, 2014 at 2:53 AM, Taylor R Campbell wrote:
>Date: Tue, 11 Nov 2014 17:42:51 +
>From: Antti Kantee
>
>2: init_main ordering
>
>I think that "code reading" is an absolute requirement there, i.e. we
>should be able to know offline what will happen at ru
On Nov 12, 1:46am, Masao Uebayashi wrote:
} On Wed, Nov 12, 2014 at 1:15 AM, Kamil Rytarowski wrote:
} > From David Holland
} >> Please don't do that. Nothing good can come of it - you are asking for
} >> a thousand weird problems where undisclosed ordering dependencies
} >> silently manifest as
Date: Tue, 11 Nov 2014 17:42:51 +
From: Antti Kantee
2: init_main ordering
I think that "code reading" is an absolute requirement there, i.e. we
should be able to know offline what will happen at runtime. Maybe that
problem is better addressed with an offline pre
Date: Tue, 11 Nov 2014 17:42:51 +
From: Antti Kantee
2: init_main ordering
I think that "code reading" is an absolute requirement there, i.e. we
should be able to know offline what will happen at runtime. Maybe that
problem is better addressed with an offline pre
There are two separate issues here:
1: link sets vs. ctors
They are exactly the same thing in slightly different clothing. Mental
exercise: define link_set_ctor and run those in kernel bootstrap when
you'd run __attribute__((constructor)). As David cautions, I don't
think ctors shou
From: Masao Uebayashi
>
> The biggest problem of constructors (and indirect function call in
> general), I am aware of, is, static code analysis (code reading, tag
> jump, ...) becomes difficult (or impossible).
>
Limited static code analysis is not a bigger problem then a broken machine at
boo
On Wed, Nov 12, 2014 at 1:15 AM, Kamil Rytarowski wrote:
> From David Holland
>> Please don't do that. Nothing good can come of it - you are asking for
>> a thousand weird problems where undisclosed ordering dependencies
>> silently manifest as strange bugs.
Everyone is aware of that. Code conve
>From David Holland
> Please don't do that. Nothing good can come of it - you are asking for
> a thousand weird problems where undisclosed ordering dependencies
> silently manifest as strange bugs.
>
> Furthermore, the compiler can and probably will assume that
> constructor functions get called b
On Sun, Nov 09, 2014 at 04:16:13PM +0900, Masao Uebayashi wrote:
> +#if 0
> #ifndef PIPE_SOCKETPAIR
> /* Initialize pipes. */
> pipe_init();
> @@ -604,6 +605,15 @@ main(void)
> /* Initialize ptrace. */
> ptrace_init();
> #endif /* PTRACE */
> +#else
> +typedef vo
On Nov 11, 2014 5:44 AM, "Masao Uebayashi" wrote:
>
> On Tue, Nov 11, 2014 at 11:48 AM, Thor Lancelot Simon
wrote:
> > On Sun, Nov 09, 2014 at 04:16:13PM +0900, Masao Uebayashi wrote:
> >> Ideally the long hardcoded sequence of init functions in
init_main:main() is
> >> converted to a single vect
On Tue, Nov 11, 2014 at 11:48 AM, Thor Lancelot Simon wrote:
> On Sun, Nov 09, 2014 at 04:16:13PM +0900, Masao Uebayashi wrote:
>> Ideally the long hardcoded sequence of init functions in init_main:main() is
>> converted to a single vector whose order is resolved by modular dependency.
>> But for
On Sun, Nov 09, 2014 at 04:16:13PM +0900, Masao Uebayashi wrote:
> Ideally the long hardcoded sequence of init functions in init_main:main() is
> converted to a single vector whose order is resolved by modular dependency.
> But for the moment such a hardcoded priority should be good enough to impro
On Mon, Nov 10, 2014 at 11:27 AM, Masao Uebayashi wrote:
> Hard to be uglier than how init_main.c looks like now...
Can't disagree there.
Justin
On Mon, Nov 10, 2014 at 7:46 PM, Justin Cormack
wrote:
>
> On Nov 10, 2014 10:02 AM, "Masao Uebayashi" wrote:
>>
>> __attribute__((constructor(n))), where n being priority, can do
>> ordering (hint from pooka@).
>>
>> Question is, how to provide __CTOR_LIST__, __CTOR_LIST_END__ equivalent
>> symb
On Nov 10, 2014 10:02 AM, "Masao Uebayashi" wrote:
>
> __attribute__((constructor(n))), where n being priority, can do
> ordering (hint from pooka@).
>
> Question is, how to provide __CTOR_LIST__, __CTOR_LIST_END__ equivalent
symbols.
>
> (It is super easy if MI linker script is there. :)
Constru
On Mon, Nov 10, 2014 at 5:25 PM, Martin Husemann wrote:
> On Sun, Nov 09, 2014 at 05:46:21PM -0800, Matt Thomas wrote:
>> No more link sets please.
>
> I agree.
I agreed one week ago. But now I have MI linker script that merges
"link_set_*" into .rodata, I can live with link-set. :)
>> Can't we
On Sun, Nov 09, 2014 at 05:46:21PM -0800, Matt Thomas wrote:
> No more link sets please.
I agree.
> Can't we use __attributes__((__constructor__))
> and __attributes__((destructor));
How about splitting the $subsystem_init() function from the function
marked as __constructor__: let the construct
> On Nov 8, 2014, at 11:16 PM, Masao Uebayashi wrote:
>
> Ideally the long hardcoded sequence of init functions in init_main:main() is
> converted to a single vector whose order is resolved by modular dependency.
> But for the moment such a hardcoded priority should be good enough to improve
> m
Ideally the long hardcoded sequence of init functions in init_main:main() is
converted to a single vector whose order is resolved by modular dependency.
But for the moment such a hardcoded priority should be good enough to improve
modularity.
Question - where to put the declarations (typedef, __li
22 matches
Mail list logo
