On 06/23/2010 05:35 PM, Daniël Mantione wrote:
It's a non-issue. If you set a thread realtime you know what you are
doing and can take care you give up the CPU when feasible, or you
simply don't enter mutuxes shared with non-realtime threads.
I don't agree.
If the RTL provides a method, it
On 06/23/2010 06:04 PM, Henry Vermaak wrote:
That only means that it doesn't send the lock signal to the external
memory manager, so you can't have a multi processor implementation
using this processor. It doesn't affect the working of the swp
instruction.
I understand the external memory
On 06/23/2010 09:26 PM, Florian Klämpfl wrote:
I'am sure if it's a problem for somebody, he will find a solution and
send a patch.
As the swap instruction seems to be the only atomic memory operation ARM
lower than v6 can do, there is no possible workaround in user space
software.
For a
On 24 Jun 2010, at 09:27, Michael Schnell wrote:
[ARMv5 and lower atomic exchange]
If there is no other way with this arch but an
active spinning lock,
There is indeed none.
the blocked thread should at least give up it's
current time slice before retrying to get the lock, so that the
Michael Schnell schrieb:
On 06/23/2010 05:35 PM, Daniël Mantione wrote:
It's a non-issue. If you set a thread realtime you know what you are
doing and can take care you give up the CPU when feasible, or you
simply don't enter mutuxes shared with non-realtime threads.
I don't agree.
If
Op Thu, 24 Jun 2010, schreef Michael Schnell:
On 06/23/2010 05:35 PM, Daniël Mantione wrote:
It's a non-issue. If you set a thread realtime you know what you are
doing and can take care you give up the CPU when feasible, or you
simply don't enter mutuxes shared with non-realtime threads.
On 06/24/2010 10:02 AM, Florian Klaempfl wrote:
Well, yes, you shouldn't simply use locked operations in a single cpu
environment, your application should provide different algorithms for
single and multi cpu/threaded environments if the application really
contains speed critical code
On 06/24/2010 10:10 AM, Daniël Mantione wrote:
Yes, but in a multi-cpu system giving up the timeslice is a very bad
idea, because the lock might be released a few clock cycles later by
the other cpu; you would waste the rest of time slice while you could
be crunching
Of course you are right.
Michael Schnell schrieb:
On 06/24/2010 10:02 AM, Florian Klaempfl wrote:
Well, yes, you shouldn't simply use locked operations in a single cpu
environment, your application should provide different algorithms for
single and multi cpu/threaded environments if the application really
contains
On 24 June 2010 09:00, Michael Schnell mschn...@lumino.de wrote:
On 06/23/2010 09:26 PM, Florian Klämpfl wrote:
I'am sure if it's a problem for somebody, he will find a solution and
send a patch.
As the swap instruction seems to be the only atomic memory operation ARM
lower than v6 can do,
On 06/24/2010 10:23 AM, Florian Klaempfl wrote:
Nobody provided either code yet which makes dynamic use of strex/ldex
as newer arms provide as I did e.g. for move using pld if available
because I needed it.
The code using strex/ldex is in place for ARMv6 and ARMv7. I don't doubt
that same
On 24 June 2010 09:16, Michael Schnell mschn...@lumino.de wrote:
On 06/24/2010 10:10 AM, Daniël Mantione wrote:
Yes, but in a multi-cpu system giving up the timeslice is a very bad
idea, because the lock might be released a few clock cycles later by
the other cpu; you would waste the rest of
Michael Schnell schrieb:
On 06/24/2010 10:23 AM, Florian Klaempfl wrote:
Nobody provided either code yet which makes dynamic use of strex/ldex
as newer arms provide as I did e.g. for move using pld if available
because I needed it.
The code using strex/ldex is in place for ARMv6 and
On 06/24/2010 11:05 AM, Henry Vermaak wrote:
/* Atomic compare and exchange. These sequences are not actually atomic;
there is a race if *MEM != OLDVAL and we are preempted between the two
swaps. However, they are very close to atomic, and are the best that a
pre-ARMv6
On 06/24/2010 11:23 AM, Florian Klaempfl wrote:
But it is not used dynamically: if you compile for arm linux, you get
the ARMv5 code path even if the code runs on ARMv6+
I see.
I suppose somewhere you can define that you want RMv6+ code. I would do
this whenever possible.
Maybe providing
On 06/24/2010 11:21 AM, Henry Vermaak wrote:
SMP is not supported by the kernel for arch armv6.
Great !
So nothing serious needs to be done about that. Maybe automatically
detecting the arch and using the best possible code for atomicness would
be a good way to go.
-Michael
On 24 June 2010 10:05, Henry Vermaak henry.verm...@gmail.com wrote:
The linux specific code is here:
http://www.eglibc.org/cgi-bin/viewcvs.cgi/trunk/ports/sysdeps/unix/sysv/linux/arm/nptl/bits/atomic.h?rev=3063view=markup
It relies completely on the kernel.
Which exposes the user helpers
On 06/24/2010 12:23 PM, Henry Vermaak wrote:
Which exposes the user helpers here:
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=arch/arm/kernel/entry-armv.S;h=7ee48e7f8f318a7b453e12849b60a6832bb85770;hb=HEAD#l767
Yep.
These are segment of kernel provided
On 06/24/2010 12:17 PM, Michael Schnell wrote:
Maybe automatically
detecting the arch and using the best possible code for atomicness would
be a good way to go.
Even better: as you found the fixed addresses implementations same
should be used having the Kernel automatically provide the
Daniël Mantione schrieb:
Yes, but in a multi-cpu system giving up the timeslice is a very bad
idea, because the lock might be released a few clock cycles later by the
other cpu; you would waste the rest of time slice while you could be
crunching.
IMO the default implementation should work
Op 2010-06-22 15:31, Marco van de Voort het geskryf:
Same problem. You still have to interface with the kernel, and it would be
incompatible with C libraries that use threads.
Well, if I don't use C libraries (only Object Pascal code), then it should
still be beneficial. I can then write
Op Wed, 23 Jun 2010, schreef Graeme Geldenhuys:
Op 2010-06-22 15:31, Marco van de Voort het geskryf:
Same problem. You still have to interface with the kernel, and it would be
incompatible with C libraries that use threads.
Well, if I don't use C libraries (only Object Pascal code), then
Marco van de Voort schrieb:
The problem is not the programming (since a dedicated person could probably
start with a translated glibc in a good month), but the continuous
maintenance (for every distribution separately, since they could use
different kernels, options etc) , and interoperability
On 06/22/2010 05:18 PM, Florian Klaempfl wrote:
At least according to Linus, the kernel api/syscall interface will never
break.
Regarding Threads, as far as I understand, the thread aware APIs (e.g.
NPTL and FUTEX) have been added, while the other APIs were not affected.
(No wonder, as I
On 06/22/2010 03:35 PM, Henry Vermaak wrote:
So maybe the fpc syscall interface needs to be updated. Can you give
any examples of what got reworked?
I don't suppose we already have NPTL and FUTEX, as same are used by
libc, anyway. If we want perfect performance and good (Posix-like)
behavior
On 06/22/2010 02:49 PM, Graeme Geldenhuys wrote:
http://linas.org/linux/threads-faq.html
This is _very_ old (1996).
they say:
Kernel-Threads
Kernel-level threads often are implemented in the kernel using several
tables
This might be true, but we now have a ubiquitous and stable NPTL
On 06/22/2010 02:55 PM, Michael Van Canneyt wrote:
For the kernel interface: Not so much. (on some archs, FUTEX is missing).
Yep.
The problem starts if you start linking to C libraries. In that case
you're
pretty much forced to use pthreads; each distribution can make different
choices
On 06/22/2010 02:57 PM, Graeme Geldenhuys wrote:
Of course you can avoid using the library, do the stuff in Pascal and
directly access the Kernel API, but this might be dangerous in case the
API might be modified some time in the future
Wouldn't the same apply to the pthreads library?
On 23/06/10 11:44, Michael Schnell wrote:
On 06/22/2010 05:18 PM, Florian Klaempfl wrote:
At least according to Linus, the kernel api/syscall interface will never
break.
Regarding Threads, as far as I understand, the thread aware APIs (e.g.
NPTL and FUTEX) have been added, while the other
In our previous episode, Hans-Peter Diettrich said:
start with a translated glibc in a good month), but the continuous
maintenance (for every distribution separately, since they could use
different kernels, options etc) , and interoperability with C code would be
killing.
The Kylix-like
On 06/22/2010 03:12 PM, Henry Vermaak wrote:
No, the syscall api is very stable, so minimum maintenance is
required. Which architectures don't provide futex? I'm not aware of
any.
The FUTEX Kernel API only makes sense, if the arch provides the
appropriate atomic operations to perform the
On 06/23/2010 01:21 PM, Henry Vermaak wrote:
There are no magic NPTL APIs: both NPTL and LinuxThreads use the
clone system call.
Yep. Additional clone flags have been added with newer Kernels (see
man clone).
Moreover for NPTL there are thread IDs additional to process IDs Same
can be obtained
On 06/23/2010 01:37 PM, Henry Vermaak wrote:
I still can't find which arches miss futex, and I can't find this
information in the manpages, either. Can you point me to where you've
found this information?
At least in the Linux Kernel Mailing list there are several discussions
on Futex (e.g.
On 23 June 2010 13:23, Michael Schnell mschn...@lumino.de wrote:
If they show up that does not mean there really is a valid
implementation. I don't know which archs are provided with the Linus
Tree, but at least with some embedded Kernels trees there only is
some dummy code, just providing
On 06/23/2010 02:45 PM, Henry Vermaak wrote:
I think you'll first have to worry porting fpc to those architectures.
Right you are :)
But anyway, if not using libc, you need to do the FUTEX user space part
in Pascal/Assembler
- With X86 using the appropriate assembler instructions (such as
On 23 June 2010 13:58, Michael Schnell mschn...@lumino.de wrote:
On 06/23/2010 02:45 PM, Henry Vermaak wrote:
I think you'll first have to worry porting fpc to those architectures.
Right you are :)
But anyway, if not using libc, you need to do the FUTEX user space part
in Pascal/Assembler
Op Wed, 23 Jun 2010, schreef Henry Vermaak:
On 23 June 2010 13:58, Michael Schnell mschn...@lumino.de wrote:
On 06/23/2010 02:45 PM, Henry Vermaak wrote:
I think you'll first have to worry porting fpc to those architectures.
Right you are :)
But anyway, if not using libc, you need to do
On 23 June 2010 14:03, Daniël Mantione daniel.manti...@freepascal.org wrote:
Op Wed, 23 Jun 2010, schreef Henry Vermaak:
On 23 June 2010 13:58, Michael Schnell mschn...@lumino.de wrote:
On 06/23/2010 02:45 PM, Henry Vermaak wrote:
I think you'll first have to worry porting fpc to those
On 06/23/2010 03:00 PM, Henry Vermaak wrote:
Why would you want to do that? Just use the futex syscall.
Here you are definitely wrong.
Futex is all about _not_ doing a syscall (i.e. change from user space to
Kernel space and back) but doing the Mutex operation in user space, if
possible (i.e.
Op Wed, 23 Jun 2010, schreef Henry Vermaak:
A futex syscall doesn't know anything about threads, it's for locking.
Perhaps I'm misunderstanding you?
I have should have written futex instead of threads. With a Futex, you
only call the Futex syscall, if the Futex is locked. You still have to
On 06/23/2010 03:08 PM, Henry Vermaak wrote:
A futex syscall doesn't know anything about threads, it's for locking.
Perhaps I'm misunderstanding you?
The Futex syscall does not lock a Mutex at all. It's a helper for the
user space locking action and performs the putting a thread to sleep
On 23 June 2010 14:22, Henry Vermaak henry.verm...@gmail.com wrote:
On 23 June 2010 14:13, Daniël Mantione daniel.manti...@freepascal.org wrote:
Op Wed, 23 Jun 2010, schreef Henry Vermaak:
A futex syscall doesn't know anything about threads, it's for locking.
Perhaps I'm misunderstanding
Marco van de Voort schrieb:
The Kylix-like addition of an C compiler would help to solve such
issues, that arise from the use of *any* C code with FPC.
Well, since this is about a maintenance problem, it would only solve
it if the maintenance of the C compiler would be lower than the
On 06/23/2010 03:56 PM, Henry Vermaak wrote:
We've got this already, then:
http://www.freepascal.org/docs-html/rtl/system/interlockedcompareexchange.html
nice !
X86, X68-64: good.
ARMV6 uses ldrex (seemingly = load locked): good
Other ARMs (including thumb2) uses a loop with result
On 23 Jun 2010, at 16:26, Michael Schnell wrote:
PPC, PPC64, Sparc: loop: not reliable
interlocked* is implemented correctly in the RTL and functions 100%
reliably on the above architectures. Please don't make such
categorical statements if you are unfamiliar with the architectures
Michael Schnell schrieb:
PPC, PPC64, Sparc: loop: not reliable
I can only speak for sparc (because I implemented them initially): they
are implemented according to official sparc docs. Do you know more then
them?
___
fpc-devel maillist -
On 23/06/10 15:26, Michael Schnell wrote:
Other ARMs (including thumb2) uses a loop with result compare. AFAIK
this does not work reliably. I am not sure it it's really true that ARM
No, SWP is atomic, so the implementation looks good (at a glance).
Henry
On 06/23/2010 04:38 PM, Florian Klaempfl wrote:
I can only speak for sparc (because I implemented them initially): they
are implemented according to official sparc docs. Do you know more then
them?
Sorry if I have been sounding rude :(.
I learned that If there is no hardware support,
On 06/23/2010 04:49 PM, Henry Vermaak wrote:
On 23/06/10 15:26, Michael Schnell wrote:
Other ARMs (including thumb2) uses a loop with result compare. AFAIK
this does not work reliably. I am not sure it it's really true that ARM
No, SWP is atomic, so the implementation looks good (at a
Michael Schnell wrote:
unfortunately we are in a realtime system and the priority of thread 2
is set higher than that of thread 1 and thus thread 1 never gets a CPU
Priority inversion? Isn't this a problem with any InterlockedC/E?
Micha
___
On Wed, 23 Jun 2010 17:12:29 +0200
Michael Schnell mschn...@lumino.de wrote:
On 06/23/2010 04:49 PM, Henry Vermaak wrote:
On 23/06/10 15:26, Michael Schnell wrote:
Other ARMs (including thumb2) uses a loop with result compare. AFAIK
this does not work reliably. I am not sure it it's
On 06/23/2010 04:49 PM, Henry Vermaak wrote:
No, SWP is atomic, so the implementation looks good (at a glance).
Seemingly not on all ARM sub-archs:
From some ARM manual:
The ARM7500FE does not use the lock feature available in the ARM701
macrocell
You must take care to ensure that
On 06/23/2010 05:15 PM, Micha Nelissen wrote:
Priority inversion? Isn't this a problem with any InterlockedC/E?
Priority inversion here leads to an unavoidable deadlock. Normal
priority inversion only reduces the priority of a high priority thread
to that of a lower priority thread that holds
On 06/23/2010 05:18 PM, Mattias Gaertner wrote:
What system has such an unfair scheduler?
A fair Scheduler only can be fair if time slices are to be managed. If
you set a thread to a realtime priority (OK, you need to be root to be
allowed to do that :) ) it's priority is above all the normal
Sorry if I have been sounding rude:(.
-Michael
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Op Wed, 23 Jun 2010, schreef Michael Schnell:
On 06/23/2010 05:18 PM, Mattias Gaertner wrote:
What system has such an unfair scheduler?
A fair Scheduler only can be fair if time slices are to be managed. If
you set a thread to a realtime priority (OK, you need to be root to be
allowed to
Michael Schnell wrote:
On 06/23/2010 04:49 PM, Henry Vermaak wrote:
No, SWP is atomic, so the implementation looks good (at a glance).
Seemingly not on all ARM sub-archs:
From some ARM manual:
The ARM7500FE does not use the lock feature available in the ARM701
macrocell
You must
On 23/06/10 16:19, Michael Schnell wrote:
On 06/23/2010 04:49 PM, Henry Vermaak wrote:
No, SWP is atomic, so the implementation looks good (at a glance).
Seemingly not on all ARM sub-archs:
From some ARM manual:
The ARM7500FE does not use the lock feature available in the ARM701
Michael Schnell schrieb:
On 06/23/2010 04:49 PM, Henry Vermaak wrote:
No, SWP is atomic, so the implementation looks good (at a glance).
Seemingly not on all ARM sub-archs:
From some ARM manual:
The ARM7500FE does not use the lock feature available in the ARM701
macrocell
You
Michael Schnell schrieb:
From some ARM manual:
The ARM7500FE does not use the lock feature available in the ARM701
macrocell
You must take care to ensure that control of the memory is not
removed from the ARM
processor while it is performing this instruction.
This seems to apply
OK, the subject sounded vaguely familiar, so when I Googled it, I found my
own posting back in 2009 asking the same questions. :-) I'll extend the
wiki multi-threading page with the answers that was given last time.
Just another question. Windows gets its threading support from the Win API.
In our previous episode, Graeme Geldenhuys said:
If these questions are answered somewhere on the wiki, then just pointing
me in that direction please.
I know that to threading support is optional in Linux/Unix apps, and is
always available under Windows (not sure about Macs).
* What is
On 22/06/10 11:40, Graeme Geldenhuys wrote:
OK, the subject sounded vaguely familiar, so when I Googled it, I found my
own posting back in 2009 asking the same questions. :-) I'll extend the
wiki multi-threading page with the answers that was given last time.
Just another question. Windows
On 06/22/2010 12:40 PM, Graeme Geldenhuys wrote:
Just another question. Windows gets its threading support from the Win API.
Similar for OS/2. Doesn't the Linux kernel have a similar threading API, or
do they just rely on the C library?
The Linux Way is more like doing separate executable
In our previous episode, Henry Vermaak said:
If not, then I gather the C library (libc, glibc or whatever is used these
days) implemented threading in C code using the POSIX spec as the guide. So
couldn't one implement the POSIX spec (thinking of threading support only)
in pure Object
On 22 June 2010 13:24, Marco van de Voort mar...@stack.nl wrote:
In our previous episode, Henry Vermaak said:
Yes, but that would probably be a very daunting task.
The problem is not the programming (since a dedicated person could probably
start with a translated glibc in a good month), but
On 22 June 2010 13:13, Michael Schnell mschn...@lumino.de wrote:
Thus older Linux Kernels did not have special threading support.
Threading could be done using clone() (instead of fork() ) to create
processes that share some resources (e.g. memory). The kernel did not
Threading is still done
Op 2010-06-22 14:24, Marco van de Voort het geskryf:
No, not straight away. That is technically impossible without integrating a
full C compiler, since POSIX requires to be able to read and interpret
And what if one implements a non-posix based implementation (of Free
Pascal's own design)
On Tue, 22 Jun 2010, Graeme Geldenhuys wrote:
Op 2010-06-22 14:24, Marco van de Voort het geskryf:
No, not straight away. That is technically impossible without integrating a
full C compiler, since POSIX requires to be able to read and interpret
And what if one implements a non-posix
Op 2010-06-22 14:13, Michael Schnell het geskryf:
The Linux Way is more like doing separate executable than doing
threads, as Linux always provided high-performance inter process
communication (e.g. pipes, usable with select() etc.) and process
starting ( fork() ).
Form the previous links I
Op 2010-06-22 14:55, Michael Van Canneyt het geskryf:
It would be nice to have a kernel interface, though. That way you could have
threading support without pulling in libc.
Exactly. The less we rely on other libraries the better. :)
Regards,
- Graeme -
--
fpGUI Toolkit - a
On 22 June 2010 13:55, Michael Van Canneyt mich...@freepascal.org wrote:
The problem starts if you start linking to C libraries. In that case you're
pretty much forced to use pthreads;
Why is that? I thought you could use anything, as long as it's posix compliant?
Henry
On 22 June 2010 13:13, Michael Schnell mschn...@lumino.de wrote:
Of course you can avoid using the library, do the stuff in Pascal and
directly access the Kernel API, but this might be dangerous in case the
API might be modified some time in the future or if it's different with
different
On Tue, 22 Jun 2010, Henry Vermaak wrote:
On 22 June 2010 13:55, Michael Van Canneyt mich...@freepascal.org wrote:
The problem starts if you start linking to C libraries. In that case you're
pretty much forced to use pthreads;
Why is that? I thought you could use anything, as long as
On 22 June 2010 14:16, Michael Van Canneyt mich...@freepascal.org wrote:
On Tue, 22 Jun 2010, Henry Vermaak wrote:
On 22 June 2010 13:55, Michael Van Canneyt mich...@freepascal.org wrote:
The problem starts if you start linking to C libraries. In that case
you're
pretty much forced to use
On 22 Jun 2010, at 15:01, Henry Vermaak wrote:
On 22 June 2010 13:55, Michael Van Canneyt mich...@freepascal.org
wrote:
The problem starts if you start linking to C libraries. In that
case you're
pretty much forced to use pthreads;
Why is that? I thought you could use anything, as
In our previous episode, Henry Vermaak said:
The problem is not the programming (since a dedicated person could probably
start with a translated glibc in a good month), but the continuous
maintenance (for every distribution separately, since they could use
different kernels, options etc) ,
In our previous episode, Graeme Geldenhuys said:
Op 2010-06-22 14:24, Marco van de Voort het geskryf:
No, not straight away. That is technically impossible without integrating a
full C compiler, since POSIX requires to be able to read and interpret
And what if one implements a non-posix
In our previous episode, Henry Vermaak said:
[ Charset ISO-8859-1 unsupported, converting... ]
On 22 June 2010 13:55, Michael Van Canneyt mich...@freepascal.org wrote:
The problem starts if you start linking to C libraries. In that case you're
pretty much forced to use pthreads;
Why is
On 22 June 2010 14:29, Marco van de Voort mar...@stack.nl wrote:
In our previous episode, Henry Vermaak said:
The problem is not the programming (since a dedicated person could probably
start with a translated glibc in a good month), but the continuous
maintenance (for every distribution
On 22 June 2010 14:33, Marco van de Voort mar...@stack.nl wrote:
In our previous episode, Henry Vermaak said:
[ Charset ISO-8859-1 unsupported, converting... ]
On 22 June 2010 13:55, Michael Van Canneyt mich...@freepascal.org wrote:
The problem starts if you start linking to C libraries. In
In our previous episode, Henry Vermaak said:
The syscall interface is very stable, so you wouldn't have to touch
anything there. ?I haven't looked at the nptl source, yet, what do they
use that changes between distros?
The syscall interface now only uses a subset of relatively the oldest
In our previous episode, Henry Vermaak said:
Why is that? ?I thought you could use anything, as long as it's posix
compliant?
Good luck getting all the C libs to use your POSIX compatible threading
model.
The reason for creating a native threading implementations is that you
_don't_
On 22 June 2010 14:38, Marco van de Voort mar...@stack.nl wrote:
In our previous episode, Henry Vermaak said:
Why is that? ?I thought you could use anything, as long as it's posix
compliant?
Good luck getting all the C libs to use your POSIX compatible threading
model.
The reason for
In our previous episode, Henry Vermaak said:
Why would you need a native one in the first place?
I was under the impression that fpc uses libc to implement threads on
unix. Is this not the case?
Yes. And 99% of the thread using programs also use other C libs that use
libc anyway (*)
As
On 22 June 2010 14:46, Marco van de Voort mar...@stack.nl wrote:
In our previous episode, Henry Vermaak said:
Why would you need a native one in the first place?
I was under the impression that fpc uses libc to implement threads on
unix. Is this not the case?
Yes. And 99% of the thread
In our previous episode, Henry Vermaak said:
Yes. And 99% of the thread using programs also use other C libs that use
libc anyway (*)
So, to answer your question above about why we need a native one: so
we can do away with the libc dependency.
In 0.1% of the programs. The rest doesn't
On 22 June 2010 15:21, Marco van de Voort mar...@stack.nl wrote:
The cure is ten times more difficult than the problem. (namely that the
That seems quite clear.
Libc breaks often, but I'm sure that a native lib will break much more
I certainly haven't experienced this libc that breaks often.
In our previous episode, Henry Vermaak said:
The cure is ten times more difficult than the problem. (namely that the
That seems quite clear.
Libc breaks often, but I'm sure that a native lib will break much more
I certainly haven't experienced this libc that breaks often.
Keep in mind
Marco van de Voort schrieb:
In our previous episode, Henry Vermaak said:
The cure is ten times more difficult than the problem. (namely that the
That seems quite clear.
Libc breaks often, but I'm sure that a native lib will break much more
I certainly haven't experienced this libc that
In our previous episode, Florian Klaempfl said:
In our previous episode, Henry Vermaak said:
The cure is ten times more difficult than the problem. (namely that the
That seems quite clear.
Libc breaks often, but I'm sure that a native lib will break much more
I certainly haven't
In our previous episode, Marco van de Voort said:
At least according to Linus, the kernel api/syscall interface will never
break.
They will just not implement new calls on new archs ? :-)
Euh, old calls obviously.
___
fpc-devel maillist -
On 22 June 2010 16:15, Marco van de Voort mar...@stack.nl wrote:
In our previous episode, Henry Vermaak said:
The cure is ten times more difficult than the problem. (namely that the
That seems quite clear.
Libc breaks often, but I'm sure that a native lib will break much more
I certainly
On 22 June 2010 16:18, Florian Klaempfl flor...@freepascal.org wrote:
Marco van de Voort schrieb:
In our previous episode, Henry Vermaak said:
The cure is ten times more difficult than the problem. (namely that the
That seems quite clear.
Libc breaks often, but I'm sure that a native lib
In our previous episode, Henry Vermaak said:
At least according to Linus, the kernel api/syscall interface will never
break.
Never say never, things will be added, but not taken away. There are
some very old programs that still run fine on new kernels. I've read
that someone has
Marco van de Voort schrieb:
In our previous episode, Marco van de Voort said:
At least according to Linus, the kernel api/syscall interface will never
break.
They will just not implement new calls on new archs ? :-)
Euh, old calls obviously.
Well, adding a new arch is not breaking old
In our previous episode, Florian Kl?mpfl said:
In our previous episode, Marco van de Voort said:
At least according to Linus, the kernel api/syscall interface will never
break.
They will just not implement new calls on new archs ? :-)
Euh, old calls obviously.
Well, adding a new
Marco van de Voort wrote:
Huh? Do stock Linux kernels still support a.out? Since afaik ELF was only added
in
1.1.52 ?
It's a kernel option to support it. Most distro's choose module here I
think? (Autodetect when used)
Micha
___
fpc-devel
On 22 June 2010 21:31, Micha Nelissen mi...@neli.hopto.org wrote:
Marco van de Voort wrote:
Huh? Do stock Linux kernels still support a.out? Since afaik ELF was only
added in
1.1.52 ?
It's a kernel option to support it. Most distro's choose module here I
think? (Autodetect when used)
Yes,
99 matches
Mail list logo
