libposix-development Mailing List for libposix (Page 8)

SourceForge Headquarters 225 Broadway Suite 1600 San Diego, CA 92101 +1 (858) 422-6466

On Thu, Jun 4, 2009 at 12:38 AM, Henrique Almeida <hd...@gm...> wrote:

>  Applied.

Did you do git push? Because I don't see it.

Regards,
Andreas

 There's an interesting point: maybe if we make a derivative work we
can relicense BSD code. For example, an application that uses BSD code
can be licensed as a proprietary application.

"Copyleft licenses such as the GNU GPL insist that modified versions
of the program must be free software as well. Non-copyleft licenses do
not insist on this."

http://www.gnu.org/philosophy/bsd.html

 Oh, the licensing hell... :-(

2009/6/3 Henrique Almeida <hd...@gm...>:
>  In the beginning of the project I wasn't sure on which license to
> choose, but I've decided to choose the BSD license because of the
> following:
>
>  - It's compatible with the GPL
>  - It's not "copyleft"
>  - It's widely used by our target audience (eg, in linux, BSD and Mac)
>  - AFAICT It's a generally known license, even in realms outside Unix
> or free software
>
>  It would be perfect if libposix had a single license. This is
> specially important for companies that would like to use libposix. The
> 3 clause license seemed okay for me, but both NetBSD and FreeBSD use a
> two clause license. The difference is the clause "Neither the name of
> the <organization> nor the names of its contributors may be used to
> endorse or promote products derived from this software without
> specific prior written permission." Since we're not a defined
> organization, we could skip that too. We have a few choices:
>
>  - Keep with the 3 clause license. We could define the "libposix
> group" just to keep with the "non endorsement" restriction. As long as
> we don't actually copy and paste code, I think it's safe to, at least
> read other BSD code (I'm not a lawyer, though). :-P
>  - Change to a 2 clause license. In this case, we can freely copy and
> paste NetBSD and FreeBSD code, for example.
>  - Allow mixing of all BSD-like licenses (that are compatible with GPL
> and are not copyleft). Not the ideal world, but no lawyer would die
> either.
>
>  The BSD licenses are explained in:
>
>  http://en.wikipedia.org/wiki/BSD_licenses
>
>  Everybody must read this, since your code will be licensed with it.
> Basically, it means that people can do almost anything with your code
> (for example, make money with it), but can't claim that you didn't
> write it.
>
> --
>  Henrique Dante de Almeida
>  hd...@gm...
>

-- 
 Henrique Dante de Almeida
 hd...@gm...

 In the beginning of the project I wasn't sure on which license to
choose, but I've decided to choose the BSD license because of the
following:

 - It's compatible with the GPL
 - It's not "copyleft"
 - It's widely used by our target audience (eg, in linux, BSD and Mac)
 - AFAICT It's a generally known license, even in realms outside Unix
or free software

 It would be perfect if libposix had a single license. This is
specially important for companies that would like to use libposix. The
3 clause license seemed okay for me, but both NetBSD and FreeBSD use a
two clause license. The difference is the clause "Neither the name of
the <organization> nor the names of its contributors may be used to
endorse or promote products derived from this software without
specific prior written permission." Since we're not a defined
organization, we could skip that too. We have a few choices:

 - Keep with the 3 clause license. We could define the "libposix
group" just to keep with the "non endorsement" restriction. As long as
we don't actually copy and paste code, I think it's safe to, at least
read other BSD code (I'm not a lawyer, though). :-P
 - Change to a 2 clause license. In this case, we can freely copy and
paste NetBSD and FreeBSD code, for example.
 - Allow mixing of all BSD-like licenses (that are compatible with GPL
and are not copyleft). Not the ideal world, but no lawyer would die
either.

 The BSD licenses are explained in:

 http://en.wikipedia.org/wiki/BSD_licenses

 Everybody must read this, since your code will be licensed with it.
Basically, it means that people can do almost anything with your code
(for example, make money with it), but can't claim that you didn't
write it.

-- 
 Henrique Dante de Almeida
 hd...@gm...

 Applied. Do you know if we can add the third clause to the NetBSD license ?

2009/6/3 Andreas Krennmair <akr...@go...>:
> On Wed, Jun 3, 2009 at 8:35 PM, Andreas Krennmair
> <akr...@go...> wrote:
>>
>> Hi,
>>
>>>>   - syscall_nums.h: It seems that you've copied and pasted those. That
>>>> can't be done. The original license and author must be present in the
>>>> source. Also, that license needs to be BSD (the project will have a
>>>> single license, I'll talk about this). Also, is this from a GPL libc ?
>>>> We can't refer to GPL competitors, else our library will become a
>>>> "derivative work" and we'll need to relicense it as GPL.
>>>
>>> It's from the Linux kernel's arch/x86/include/asm/unistd_64.h, with some
>>> vim magic applied. If this is unacceptable, then, well, we have a problem,
>>> as this is more or less the official reference. And even though FreeBSD has
>>> a Linux emulation, it doesn't seem to have support for Linux x86_64
>>> syscalls, at least I couldn't find anything.
>>
>> OK, I did find something usable now:
>> http://cvsweb.netbsd.org/bsdweb.cgi/src/sys/compat/linux/arch/amd64/linux_syscall.h?rev=1.32&content-type=text/x-cvsweb-markup
>> I'll correct this in my source and release a new patch.
>
> Here we go: http://synflood.at/tmp/libposix/x86_64-working-updated.mbox
>
> It's nothing but a verbatim copy of said file, which is a bit rough, but
> it's a start to keep the x86_64 port unencumbered.
>
> Regards,
> Andreas
>
>
> ------------------------------------------------------------------------------
> OpenSolaris 2009.06 is a cutting edge operating system for enterprises
> looking to deploy the next generation of Solaris that includes the latest
> innovations from Sun and the OpenSource community. Download a copy and
> enjoy capabilities such as Networking, Storage and Virtualization.
> Go to: http://p.sf.net/sfu/opensolaris-get
> _______________________________________________
> Libposix-development mailing list
> Lib...@li...
> https://lists.sourceforge.net/lists/listinfo/libposix-development
>
>

-- 
 Henrique Dante de Almeida
 hd...@gm...

2009/6/3 Andreas Krennmair <akr...@go...>:
>
> As far as I understand, the whole vsyscall thing isn't universally
> applicable, and shouldn't be, either. Also, IIRC, vsyscalls don't play
> together too well with strace.
>
> Also:
> $ ldd /bin/ls
>         librt.so.1 => /lib/librt.so.1 (0x00002b0a91436000)
>         libselinux.so.1 => /lib/libselinux.so.1 (0x00002b0a9163e000)
>         libacl.so.1 => /lib/libacl.so.1 (0x00002b0a9185a000)
>         libc.so.6 => /lib/libc.so.6 (0x00002b0a91a61000)
>         libpthread.so.0 => /lib/libpthread.so.0 (0x00002b0a91db5000)
>         /lib64/ld-linux-x86-64.so.2 (0x00002b0a91218000)
>         libdl.so.2 => /lib/libdl.so.2 (0x00002b0a91fd0000)
>         libattr.so.1 => /lib/libattr.so.1 (0x00002b0a921d4000)
> $
> No linux-vdso.so.1 here whatsoever.

 Sounds good to me. I just needed the citation. It's available in the
amd64 ABI, in the pages you've cited (obviously, we have to trust that
the ABI will be followed, but the standanrdard is a great
authoritative reference ;-)). So we can throw vsyscall away.

>
>>
>> - _start.S: is the third parameter (envp) correct ? It needs to point
>> to the first environment variable. Isn't the correct address
>> rsi+8*rdi+16 ?
>
> When stepping through the code using gdb, envp seemed to be fine. Also,
> rsi+8*rdi computes the position of the last element in argv (which is NULL),
> and so +8 points to the element next to it, which should be envp.

 Ok, the missing +8 was hidden in the first popq instruction.

>
>
> It's from the Linux kernel's arch/x86/include/asm/unistd_64.h, with some vim
> magic applied. If this is unacceptable, then, well, we have a problem, as
> this is more or less the official reference. And even though FreeBSD has a
> Linux emulation, it doesn't seem to have support for Linux x86_64 syscalls,
> at least I couldn't find anything.

 Ok, we'll need to read the linux source sometimes, because there are
things that are only documented in the source. We can only hope that
building a linux library is not considered a derivative work.

>
>
> Why would I need to save registers for the caller? I don't know which
> registers are used by the caller, so I don't know which to save.
>
> Regarding calling conventions: http://www.x86-64.org/documentation/abi.pdf
> pp. 123-124

 That's it, I just needed the reference. ;-) Elaborating: the caller
and callee must agree on who saves which registers. This is part of
the ABI. The calling conventions is further described in 3.2.3
Parameter Passing. Figure 3.4 shows that registers rax, rcx, rdx, rsi,
rdi, r8-r11 are not preserved across calls, so they can be safely
overwritten.

 Conclusion, the code is conformant. I'll add the references to the
ABI as a remark to the sources. I've installed a x86_64 linux and
hello is working flawlessly. :-)

>
> As I don't have any *BSD installations and only a Mac with an obsolete
> version of OSX that wouldn't be of much help, in the meantime I would prefer
> to work on getting the most essential system calls and some surrounding
> library infrastructure (e.g. malloc(3)) up and running, if that's ok.

 No problem. Post the functions you're working on the list, so that
people can start writing unit tests for them.

>
> I'd prefer sticking to GNU make and Makefiles, as it's powerful enough to
> solve most problems, even multi-platform support. "if it ain't broken, don't
> fix it."
> If you tell me what you want to achieve, I will adapt the Makefile for you.

 That power is exactly what I don't want in our build system. It's a
goal of this project to keep the code easy to study and easy to
mantain, and we all know how large makefiles look like. Consider that
ideally, we'd create a simple source list and the build system would
handle everything. Don't worry, we'll switch to some simpler build
system and if we find out that it's worse or it's too weak, we can
always go back.

>
> Regards,
> Andreas
>
> ------------------------------------------------------------------------------
> OpenSolaris 2009.06 is a cutting edge operating system for enterprises
> looking to deploy the next generation of Solaris that includes the latest
> innovations from Sun and the OpenSource community. Download a copy and
> enjoy capabilities such as Networking, Storage and Virtualization.
> Go to: http://p.sf.net/sfu/opensolaris-get
> _______________________________________________
> Libposix-development mailing list
> Lib...@li...
> https://lists.sourceforge.net/lists/listinfo/libposix-development
>
>

-- 
 Henrique Dante de Almeida
 hd...@gm...

On Wed, Jun 3, 2009 at 8:35 PM, Andreas Krennmair <akr...@go...
> wrote:

> Hi,
>
>   - syscall_nums.h: It seems that you've copied and pasted those. That
>>> can't be done. The original license and author must be present in the
>>> source. Also, that license needs to be BSD (the project will have a
>>> single license, I'll talk about this). Also, is this from a GPL libc ?
>>> We can't refer to GPL competitors, else our library will become a
>>> "derivative work" and we'll need to relicense it as GPL.
>>
>>
>> It's from the Linux kernel's arch/x86/include/asm/unistd_64.h, with some
>> vim magic applied. If this is unacceptable, then, well, we have a problem,
>> as this is more or less the official reference. And even though FreeBSD has
>> a Linux emulation, it doesn't seem to have support for Linux x86_64
>> syscalls, at least I couldn't find anything.
>>
>
> OK, I did find something usable now:
> http://cvsweb.netbsd.org/bsdweb.cgi/src/sys/compat/linux/arch/amd64/linux_syscall.h?rev=1.32&content-type=text/x-cvsweb-markup
> I'll correct this in my source and release a new patch.
>

Here we go: http://synflood.at/tmp/libposix/x86_64-working-updated.mbox

It's nothing but a verbatim copy of said file, which is a bit rough, but
it's a start to keep the x86_64 port unencumbered.

Regards,
Andreas

Hi,

  - syscall_nums.h: It seems that you've copied and pasted those. That
>> can't be done. The original license and author must be present in the
>> source. Also, that license needs to be BSD (the project will have a
>> single license, I'll talk about this). Also, is this from a GPL libc ?
>> We can't refer to GPL competitors, else our library will become a
>> "derivative work" and we'll need to relicense it as GPL.
>
>
> It's from the Linux kernel's arch/x86/include/asm/unistd_64.h, with some
> vim magic applied. If this is unacceptable, then, well, we have a problem,
> as this is more or less the official reference. And even though FreeBSD has
> a Linux emulation, it doesn't seem to have support for Linux x86_64
> syscalls, at least I couldn't find anything.
>

OK, I did find something usable now:
http://cvsweb.netbsd.org/bsdweb.cgi/src/sys/compat/linux/arch/amd64/linux_syscall.h?rev=1.32&content-type=text/x-cvsweb-markup
I'll correct this in my source and release a new patch.

Regards,
Andreas

On Wed, Jun 3, 2009 at 4:26 AM, Henrique Almeida <hd...@gm...> wrote:

> 2009/6/2 Andreas Krennmair <akr...@go...>:
> > On Tue, Jun 2, 2009 at 3:55 PM, Andreas Krennmair
> >
> > This patch is obsolete, here's the new patch set containing both the old
> > patch and some amendments to it that make it work on x86_64:
> > http://synflood.at/tmp/libposix/x86_64-working.mbox
>
>  Nice. Many comments, though:
>
> - x86_64 also seems to use vsyscall, as shown by the virtual library
> "vdso" shown by Tordek output (ldd /bin/ls) on the other post. Is it
> safe to use "syscall" directly ? I need a valid reference for the
> system call specification on x86_64.

As far as I understand, the whole vsyscall thing isn't universally
applicable, and shouldn't be, either. Also, IIRC, vsyscalls don't play
together too well with strace.

Also:
$ ldd /bin/ls
        librt.so.1 => /lib/librt.so.1 (0x00002b0a91436000)
        libselinux.so.1 => /lib/libselinux.so.1 (0x00002b0a9163e000)
        libacl.so.1 => /lib/libacl.so.1 (0x00002b0a9185a000)
        libc.so.6 => /lib/libc.so.6 (0x00002b0a91a61000)
        libpthread.so.0 => /lib/libpthread.so.0 (0x00002b0a91db5000)
        /lib64/ld-linux-x86-64.so.2 (0x00002b0a91218000)
        libdl.so.2 => /lib/libdl.so.2 (0x00002b0a91fd0000)
        libattr.so.1 => /lib/libattr.so.1 (0x00002b0a921d4000)
$
No linux-vdso.so.1 here whatsoever.

>
> - _start.S: is the third parameter (envp) correct ? It needs to point
> to the first environment variable. Isn't the correct address
> rsi+8*rdi+16 ?

When stepping through the code using gdb, envp seemed to be fine. Also,
rsi+8*rdi computes the position of the last element in argv (which is NULL),
and so +8 points to the element next to it, which should be envp.

>
>  - syscall_nums.h: It seems that you've copied and pasted those. That
> can't be done. The original license and author must be present in the
> source. Also, that license needs to be BSD (the project will have a
> single license, I'll talk about this). Also, is this from a GPL libc ?
> We can't refer to GPL competitors, else our library will become a
> "derivative work" and we'll need to relicense it as GPL.

It's from the Linux kernel's arch/x86/include/asm/unistd_64.h, with some vim
magic applied. If this is unacceptable, then, well, we have a problem, as
this is more or less the official reference. And even though FreeBSD has a
Linux emulation, it doesn't seem to have support for Linux x86_64 syscalls,
at least I couldn't find anything.

>   - syscalls.S: are you sure you don't need to save the register values
> for the caller ? Would the code compiled, say, as -O3 (with the
> compiler inlining functions and aggressively using registers) always
> work ? Again, I need a valid reference for the calling conventions
> specification on x86_64

Why would I need to save registers for the caller? I don't know which
registers are used by the caller, so I don't know which to save.

Regarding calling conventions:
http://www.x86-64.org/documentation/abi.pdfpp. 123-124

> Cool ! :-D The next step is port to a non linux platform. David said
> he had easy access to NetBSD and Mac OS X. David, do you think you can
> help with the port for those ?

As I don't have any *BSD installations and only a Mac with an obsolete
version of OSX that wouldn't be of much help, in the meantime I would prefer
to work on getting the most essential system calls and some surrounding
library infrastructure (e.g. malloc(3)) up and running, if that's ok.

>   Anyway, before we continue with the ports, it's a good idea to switch
> to a "next generation" build system and define how "platform set"
> configuration files will behave.

I'd prefer sticking to GNU make and Makefiles, as it's powerful enough to
solve most problems, even multi-platform support. "if it ain't broken, don't
fix it."
If you tell me what you want to achieve, I will adapt the Makefile for you.

Regards,
Andreas

 BTW, I hope to install Ubuntu amd64 here this week, so I'll be able
to help with the port.

2009/6/2 Henrique Almeida <hd...@gm...>:
> 2009/6/2 Andreas Krennmair <akr...@go...>:
>> On Tue, Jun 2, 2009 at 3:55 PM, Andreas Krennmair
>>
>> This patch is obsolete, here's the new patch set containing both the old
>> patch and some amendments to it that make it work on x86_64:
>> http://synflood.at/tmp/libposix/x86_64-working.mbox
>
>  Nice. Many comments, though:
>
> - x86_64 also seems to use vsyscall, as shown by the virtual library
> "vdso" shown by Tordek output (ldd /bin/ls) on the other post. Is it
> safe to use "syscall" directly ? I need a valid reference for the
> system call specification on x86_64.
> - _start.S: is the third parameter (envp) correct ? It needs to point
> to the first environment variable. Isn't the correct address
> rsi+8*rdi+16 ?
>  - syscall_nums.h: It seems that you've copied and pasted those. That
> can't be done. The original license and author must be present in the
> source. Also, that license needs to be BSD (the project will have a
> single license, I'll talk about this). Also, is this from a GPL libc ?
> We can't refer to GPL competitors, else our library will become a
> "derivative work" and we'll need to relicense it as GPL.
>  - syscalls.S: are you sure you don't need to save the register values
> for the caller ? Would the code compiled, say, as -O3 (with the
> compiler inlining functions and aggressively using registers) always
> work ? Again, I need a valid reference for the calling conventions
> specification on x86_64
>
>  I have setup a branch for your patches in my local repository, so you
> can have some time to answer the questions.
>
>>
>> Please note that this not only switches from nasm to GNU as but also breaks
>> current x86 support as I don't have a proper development machine to test any
>> changes to x86. But changes to get x86 running again should be trivial.
>
>  Yes, x86 compilation is broken. :-/
>
>>
>> So, in short: libposix has gone multiplatform!
>
>  Cool ! :-D The next step is port to a non linux platform. David said
> he had easy access to NetBSD and Mac OS X. David, do you think you can
> help with the port for those ?
>
>  Anyway, before we continue with the ports, it's a good idea to switch
> to a "next generation" build system and define how "platform set"
> configuration files will behave.
>
>>
>> Regards,
>> Andreas
>>
>>
>> ------------------------------------------------------------------------------
>> OpenSolaris 2009.06 is a cutting edge operating system for enterprises
>> looking to deploy the next generation of Solaris that includes the latest
>> innovations from Sun and the OpenSource community. Download a copy and
>> enjoy capabilities such as Networking, Storage and Virtualization.
>> Go to: http://p.sf.net/sfu/opensolaris-get
>> _______________________________________________
>> Libposix-development mailing list
>> Lib...@li...
>> https://lists.sourceforge.net/lists/listinfo/libposix-development
>>
>>
>
>
>
> --
>  Henrique Dante de Almeida
>  hd...@gm...
>

-- 
 Henrique Dante de Almeida
 hd...@gm...

 I've created the page. See if it can be edited.

 https://apps.sourceforge.net/mediawiki/libposix/index.php?title=Function_list

2009/5/31 Henrique Almeida <hd...@gm...>:
>  While they don't answer, I was able to put you in the "editor" group.
>
> 2009/5/31 Henrique Almeida <hd...@gm...>:
>>  I want to give full access to the wiki, but I have no idea how to do
>> that. I'll send a message to SF.
>>
>> 2009/5/31 David Rocamora <dr...@gm...>:
>>> Henrique,
>>>
>>> Can you open up the permissions on the wiki so I can create a page
>>> called "function list" or what not. I think we should start with the
>>> list we are describing there and have each function link to another
>>> wiki page if more description is needed. The wiki seems locked down
>>> now so I can't add the page myself.
>>>
>>> Thanks,
>>> Dave
>>>
>>> On Thu, May 28, 2009 at 3:23 PM, Henrique Almeida <hd...@gm...> wrote:
>>>>
>>>>
>>>> 2009/5/28 Tordek <ke...@gm...>:
>>>>> Henrique Almeida wrote:
>>>>>>  First of all, I hope the message reaches everyone, I'm not sure if
>>>>>> the mailing list is working well, so please reply to this post if
>>>>>> you've received it.
>>>>>>
>>>>>
>>>>> Yes, it is.
>>>>
>>>> Nice.
>>>>
>>>>>>  We'll start the project with a simple task. During the project we'll
>>>>>> need to mantain the list with the status of each function in the
>>>>>> project (that is, if it has been implemented, tested, etc.).
>>>>>
>>>>> Do we have a wiki, or another place to post this to? A specific
>>>>> format? (writing the full description of a function as an example
>>>>> would be a great start).
>>>>>
>>>>> I'd strongly reccomend a wiki, to make it highly navigable
>>>>> (categorizing functions per difficulty, and implementedness, for one).
>>>>
>>>> Yes, we definitely need a wiki. SF provides MediaWiki. I have activated it
>>>> on:
>>>>
>>>> http://apps.sourceforge.net/mediawiki/libposix/index.php?title=Main_Page
>>>>
>>>> However, at some moment we'll need to provide a clean and uniform (and
>>>> unique) appearance to the whole site, so we'll need to play with the CSS
>>>> stuff in the wiki. Can you do this ? (btw, we'll need to setup a task
>>>> management page too)
>>>>
>>>> At the moment, the table needs the following
>>>> - function name
>>>> - requirement (mandatory or the option group which it belongs)
>>>> - whether it's obsolescent or not
>>>> - expected difficulty
>>>>
>>>> The table will grow later, but let's keep it simple for now. For the
>>>> functions atoi, crypt and dprintf that would be:
>>>>
>>>> atoi    mandatory    (not obsolescent)    easy
>>>> crypt   XSI option   (not obsolescent)    medium
>>>> dprintf mandatory    (not obsolescent)    hard
>>>>
>>>>  There's another wiki available in SF, called Wikispaces, I don't know if it
>>>> would be better than MediaWiki, though, I've looked at their home page and
>>>> it doesn't seem to be any docs there.
>>>>
>>>>>
>>>>> --
>>>>> Guillermo O. «Tordek» Freschi. Programador, Escritor, Genio Maligno.
>>>>> http://tordek.com.ar :: http://twitter.com/tordek
>>>>> http://www.arcanopedia.com.ar - Juegos de Rol en Argentina
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Henrique Dante de Almeida
>>>> hd...@gm...
>>>>
>>>>
>>>> ------------------------------------------------------------------------------
>>>> Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT
>>>> is a gathering of tech-side developers & brand creativity professionals.
>>>> Meet
>>>> the minds behind Google Creative Lab, Visual Complexity, Processing, &
>>>> iPhoneDevCamp as they present alongside digital heavyweights like Barbarian
>>>> Group, R/GA, & Big Spaceship. http://p.sf.net/sfu/creativitycat-com
>>>> _______________________________________________
>>>> Libposix-development mailing list
>>>> Lib...@li...
>>>> https://lists.sourceforge.net/lists/listinfo/libposix-development
>>>>
>>>>
>>>
>>
>>
>>
>> --
>>  Henrique Dante de Almeida
>>  hd...@gm...
>>
>
>
>
> --
>  Henrique Dante de Almeida
>  hd...@gm...
>

-- 
 Henrique Dante de Almeida
 hd...@gm...

2009/6/2 Andreas Krennmair <akr...@go...>:
> On Tue, Jun 2, 2009 at 3:55 PM, Andreas Krennmair
>
> This patch is obsolete, here's the new patch set containing both the old
> patch and some amendments to it that make it work on x86_64:
> http://synflood.at/tmp/libposix/x86_64-working.mbox

 Nice. Many comments, though:

- x86_64 also seems to use vsyscall, as shown by the virtual library
"vdso" shown by Tordek output (ldd /bin/ls) on the other post. Is it
safe to use "syscall" directly ? I need a valid reference for the
system call specification on x86_64.
- _start.S: is the third parameter (envp) correct ? It needs to point
to the first environment variable. Isn't the correct address
rsi+8*rdi+16 ?
 - syscall_nums.h: It seems that you've copied and pasted those. That
can't be done. The original license and author must be present in the
source. Also, that license needs to be BSD (the project will have a
single license, I'll talk about this). Also, is this from a GPL libc ?
We can't refer to GPL competitors, else our library will become a
"derivative work" and we'll need to relicense it as GPL.
 - syscalls.S: are you sure you don't need to save the register values
for the caller ? Would the code compiled, say, as -O3 (with the
compiler inlining functions and aggressively using registers) always
work ? Again, I need a valid reference for the calling conventions
specification on x86_64

 I have setup a branch for your patches in my local repository, so you
can have some time to answer the questions.

>
> Please note that this not only switches from nasm to GNU as but also breaks
> current x86 support as I don't have a proper development machine to test any
> changes to x86. But changes to get x86 running again should be trivial.

 Yes, x86 compilation is broken. :-/

>
> So, in short: libposix has gone multiplatform!

 Cool ! :-D The next step is port to a non linux platform. David said
he had easy access to NetBSD and Mac OS X. David, do you think you can
help with the port for those ?

 Anyway, before we continue with the ports, it's a good idea to switch
to a "next generation" build system and define how "platform set"
configuration files will behave.

>
> Regards,
> Andreas
>
>
> ------------------------------------------------------------------------------
> OpenSolaris 2009.06 is a cutting edge operating system for enterprises
> looking to deploy the next generation of Solaris that includes the latest
> innovations from Sun and the OpenSource community. Download a copy and
> enjoy capabilities such as Networking, Storage and Virtualization.
> Go to: http://p.sf.net/sfu/opensolaris-get
> _______________________________________________
> Libposix-development mailing list
> Lib...@li...
> https://lists.sourceforge.net/lists/listinfo/libposix-development
>
>

-- 
 Henrique Dante de Almeida
 hd...@gm...

Disregard that last message, I applied the old patch by mistake.

Andreas, you, officially, rock.

-- 
Guillermo O. «Tordek» Freschi. Programador, Escritor, Genio Maligno.
http://tordek.com.ar :: http://twitter.com/tordek
http://www.arcanopedia.com.ar - Juegos de Rol en Argentina

Andreas Krennmair wrote:
> So, in short: libposix has gone multiplatform!
> 

Hate to be the bearer of bad news, but not quite:

:~/src/C/libposix$ LD_LIBRARY_PATH=output-x86_64 output-x86_64/hello

<Nothing until I press Enter.>

Segmentation fault

> Regards,
> Andreas

-- 
Guillermo O. «Tordek» Freschi. Programador, Escritor, Genio Maligno.
http://tordek.com.ar :: http://twitter.com/tordek
http://www.arcanopedia.com.ar - Juegos de Rol en Argentina

On Tue, Jun 2, 2009 at 3:55 PM, Andreas Krennmair <akr...@go...
> wrote:

> Hello everyone,
>
> I restructured the directory structure a bit, and added a preliminary
> x86-64 port which doesn't work yet, though, as calls to syscall3() somehow
> jump to the wrong address...
> Anyway, here's the patch: http://synflood.at/tmp/libposix/x86_64.mbox
> I'll continue investigating what's going on here.

This patch is obsolete, here's the new patch set containing both the old
patch and some amendments to it that make it work on x86_64:
http://synflood.at/tmp/libposix/x86_64-working.mbox

Please note that this not only switches from nasm to GNU as but also breaks
current x86 support as I don't have a proper development machine to test any
changes to x86. But changes to get x86 running again should be trivial.

So, in short: libposix has gone multiplatform!

Regards,
Andreas

Hello everyone,

I restructured the directory structure a bit, and added a preliminary x86-64
port which doesn't work yet, though, as calls to syscall3() somehow jump to
the wrong address...
Anyway, here's the patch: http://synflood.at/tmp/libposix/x86_64.mbox
I'll continue investigating what's going on here.

Regards,
Andreas

Henrique Almeida wrote:
> 2009/6/1 Andreas Krennmair <akr...@go...>:
>> I've been playing around a bit with an x86_64 port, but since I'm not an
>> expert on assembler (especially x86_64), I didn't have much luck getting
>> link my attempt of it. My last guess was that I'd need to have position
>> independent code, but then I accidently typed in "git stash drop" instead of
>> "git stash pop" and removed my work on that topic. :-/
> 

Same problem here; tho I know even _less_ assembly. :(

>  If we're lucky, x86_64 uses "syscall" directly instead of vsyscall.
> We must find out how system calls work in x86_64 (hint: post here the
> output of "ldd /bin/ls" from a x86_64 distribution).

Okay:

:~$ ldd /bin/ls
        linux-vdso.so.1 =>  (0x00007fff389fe000)
        librt.so.1 => /lib/librt.so.1 (0x00007f1230474000)
        libselinux.so.1 => /lib/libselinux.so.1 (0x00007f1230258000)
        libacl.so.1 => /lib/libacl.so.1 (0x00007f1230051000)
        libc.so.6 => /lib/libc.so.6 (0x00007f122fcfe000)
        libpthread.so.0 => /lib/libpthread.so.0 (0x00007f122fae3000)
        /lib64/ld-linux-x86-64.so.2 (0x00007f123067c000)
        libdl.so.2 => /lib/libdl.so.2 (0x00007f122f8df000)
        libattr.so.1 => /lib/libattr.so.1 (0x00007f122f6db000)

>  http://www.x86-64.org/documentation/abi.pdf
> 
>  The assembly code for x86 (_start.asm and syscalls.asm) is not
> suitable for x86_64.

Thought as much; I was actually wondering if it could compile to x86
and run in emulated mode or something.

-- 
Guillermo O. «Tordek» Freschi. Programador, Escritor, Genio Maligno.
http://tordek.com.ar :: http://twitter.com/tordek
http://www.arcanopedia.com.ar - Juegos de Rol en Argentina

 Ack.

2009/6/1 Chris Forbes <ch...@fa...>:
> Testing...
>
>
>
> WWW.FARMWORKSPFS.CO.NZ
> Chris Forbes
> Software Developer
> FARMWORKS Precision Farming Systems
> Ph: +64 6 323 9059 -
> Fax: +64 6 323 1371
> Email: ch...@fa...
>
>
>
> Attention: This e-mail is confidential and may contain information subject to legal privilege. If you are not the intended recipient please advise us of our error by return e-mail then delete this e-mail and any attached files. You may not copy, disclose or use the contents in any way. The views expressed in this e-mail may not be those of FARMWORKS Limited or subsidiary companies thereof.
>
>
>
>
> ------------------------------------------------------------------------------
> OpenSolaris 2009.06 is a cutting edge operating system for enterprises
> looking to deploy the next generation of Solaris that includes the latest
> innovations from Sun and the OpenSource community. Download a copy and
> enjoy capabilities such as Networking, Storage and Virtualization.
> Go to: http://p.sf.net/sfu/opensolaris-get
> _______________________________________________
> Libposix-development mailing list
> Lib...@li...
> https://lists.sourceforge.net/lists/listinfo/libposix-development
>

-- 
 Henrique Dante de Almeida
 hd...@gm...

2009/6/1 Andreas Krennmair <akr...@go...>:
> Hi,
> On Mon, Jun 1, 2009 at 6:48 PM, Henrique Almeida <hd...@gm...> wrote:
>>
>> > How are patches supposed to be submitted? I have two patches ready, one
>>
>>  Either join the project and get write access to the repository, or
>> just paste them into the mailing list. ;-)
>
> OK, I'll stick with posting them here so far. It's always good to have an
> explicit review process.
>
>>
>>  Thanks for the patches, I've uploaded them to the repository. Notice,
>> however, that 1) runtime support (init.o and others) is not linked
>> into libposix, only in the final application (maybe we should separate
>> the runtime source
>
> Alright.
>
>>
>> ?) 2) size_t is unsigned, so the decrement in the
>> loops are invoking undefined behavior (maybe a simpler, positive loop
>> will do, the compiler will optimize that anyway).
>
> I'm aware of that, and the code is safe: expression such as
>     while (size--) {
> are totally fine: in case size is 0, the expression size-- returns 0, which
> makes the while-loop terminate, and _then_ size is decremented. The value of
> size is undefined afterwards, but it isn't used anymore afterwards, anyway,
> in none of my submitted routines, so I see no problem with the code.

 Undefined behavior is more general than that. A processor may, for
example, trap on integer overflow (or a compiler can insert code to do
this). Anyway, I've just found out that unsigned integer arithmetic
has DEFINED modular behavior. My bad, sorry. I think a remark
suffices: keep the code as safe as possible.

>
>>
>>   The next tasks will be the inclusion of unit testing and porting
>> hello world to more platforms.
>
> I've been playing around a bit with an x86_64 port, but since I'm not an
> expert on assembler (especially x86_64), I didn't have much luck getting
> link my attempt of it. My last guess was that I'd need to have position
> independent code, but then I accidently typed in "git stash drop" instead of
> "git stash pop" and removed my work on that topic. :-/

 If we're lucky, x86_64 uses "syscall" directly instead of vsyscall.
We must find out how system calls work in x86_64 (hint: post here the
output of "ldd /bin/ls" from a x86_64 distribution). If necessary,
examples on how to deal with PIC code (and more) are on the ABI
document:

 http://www.x86-64.org/documentation/abi.pdf

 The assembly code for x86 (_start.asm and syscalls.asm) is not
suitable for x86_64.

>
> Regards,
> Andreas
>
> ------------------------------------------------------------------------------
> OpenSolaris 2009.06 is a cutting edge operating system for enterprises
> looking to deploy the next generation of Solaris that includes the latest
> innovations from Sun and the OpenSource community. Download a copy and
> enjoy capabilities such as Networking, Storage and Virtualization.
> Go to: http://p.sf.net/sfu/opensolaris-get
> _______________________________________________
> Libposix-development mailing list
> Lib...@li...
> https://lists.sourceforge.net/lists/listinfo/libposix-development
>
>

-- 
 Henrique Dante de Almeida
 hd...@gm...

Testing...

WWW.FARMWORKSPFS.CO.NZ 
Chris Forbes 
Software Developer 
FARMWORKS Precision Farming Systems
Ph: +64 6 323 9059 -
Fax: +64 6 323 1371
Email: ch...@fa...

Attention: This e-mail is confidential and may contain information subject to legal privilege. If you are not the intended recipient please advise us of our error by return e-mail then delete this e-mail and any attached files. You may not copy, disclose or use the contents in any way. The views expressed in this e-mail may not be those of FARMWORKS Limited or subsidiary companies thereof. 

Hi,
On Mon, Jun 1, 2009 at 6:48 PM, Henrique Almeida <hd...@gm...> wrote:

> > How are patches supposed to be submitted? I have two patches ready, one
>
>  Either join the project and get write access to the repository, or
> just paste them into the mailing list. ;-)

OK, I'll stick with posting them here so far. It's always good to have an
explicit review process.

>  Thanks for the patches, I've uploaded them to the repository. Notice,
> however, that 1) runtime support (init.o and others) is not linked
> into libposix, only in the final application (maybe we should separate
> the runtime source

Alright.

> ?) 2) size_t is unsigned, so the decrement in the
> loops are invoking undefined behavior (maybe a simpler, positive loop
> will do, the compiler will optimize that anyway).

I'm aware of that, and the code is safe: expression such as
    while (size--) {
are totally fine: in case size is 0, the expression size-- returns 0, which
makes the while-loop terminate, and _then_ size is decremented. The value of
size is undefined afterwards, but it isn't used anymore afterwards, anyway,
in none of my submitted routines, so I see no problem with the code.

>   The next tasks will be the inclusion of unit testing and porting
> hello world to more platforms.
>

I've been playing around a bit with an x86_64 port, but since I'm not an
expert on assembler (especially x86_64), I didn't have much luck getting
link my attempt of it. My last guess was that I'd need to have position
independent code, but then I accidently typed in "git stash drop" instead of
"git stash pop" and removed my work on that topic. :-/

Regards,
Andreas

2009/6/1 Tordek <ke...@gm...>:
> Andreas Krennmair wrote:
>> adds some multi-platform building support (i.e. it separates i386
>> binaries from e.g. x86_64 binaries), and the other one adding my
>
> I've tried your makefile, but I'm still unable to compile:

 We can't compile to x86-64 yet, "system/linux" only contains x86
assembly code, so we need to port that code. That's the right
direction, we need to port "Hello world" so that we setup our build
system for multiple target support.

>
> ld -o output-x86_64/libposix.so -shared output-x86_64/runtime.o
> output-x86_64/stdio.o output-x86_64/string.o output-x86_64/init.o
> output-x86_64/syscalls.o output-x86_64/_start.asm.o
> output-x86_64/syscalls.asm.o
> ld: i386 architecture of input file `output-x86_64/_start.asm.o' is
> incompatible with i386:x86-64 output
> ld: i386 architecture of input file `output-x86_64/syscalls.asm.o'
> is incompatible with i386:x86-64 output
>
> Changing nasm's options to -f elf64 gives the previous error again:
>
> ld: output-x86_64/syscalls.asm.o: relocation R_X86_64_32 against
> `kernel_vsyscall' can not be used when making a shared object;
> recompile with -fPIC
> output-x86_64/syscalls.asm.o: could not read symbols: Bad value
>
> --
> Guillermo O. «Tordek» Freschi. Programador, Escritor, Genio Maligno.
> http://tordek.com.ar :: http://twitter.com/tordek
> http://www.arcanopedia.com.ar - Juegos de Rol en Argentina
>
>
> ------------------------------------------------------------------------------
> Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT
> is a gathering of tech-side developers & brand creativity professionals. Meet
> the minds behind Google Creative Lab, Visual Complexity, Processing, &
> iPhoneDevCamp as they present alongside digital heavyweights like Barbarian
> Group, R/GA, & Big Spaceship. http://p.sf.net/sfu/creativitycat-com
> _______________________________________________
> Libposix-development mailing list
> Lib...@li...
> https://lists.sourceforge.net/lists/listinfo/libposix-development
>
>

-- 
 Henrique Dante de Almeida
 hd...@gm...

2009/6/1 Andreas Krennmair <akr...@go...>:
> Hi,

 Hello, Andreas,

> On Sun, May 31, 2009 at 11:46 PM, Henrique Almeida <hd...@gm...> wrote:
>>
>>  Report bugs urgently. You may use Tracker for this:
>>
>>  https://sourceforge.net/tracker/?group_id=261625
>
> How are patches supposed to be submitted? I have two patches ready, one

 Either join the project and get write access to the repository, or
just paste them into the mailing list. ;-)

> adding a Makefile that allows parallelized builds on multi-core CPUs and
> adds some multi-platform building support (i.e. it separates i386 binaries
> from e.g. x86_64 binaries), and the other one adding my previously submitted
> string functions attributed with the BSD license and reformatted to match
> the existing source formatting. So far, you can find the patches in mbox
> format here:
> http://synflood.at/tmp/libposix/makefile_stringfuncs.mbox

 Thanks for the patches, I've uploaded them to the repository. Notice,
however, that 1) runtime support (init.o and others) is not linked
into libposix, only in the final application (maybe we should separate
the runtime source ?) 2) size_t is unsigned, so the decrement in the
loops are invoking undefined behavior (maybe a simpler, positive loop
will do, the compiler will optimize that anyway).

 The next tasks will be the inclusion of unit testing and porting
hello world to more platforms.

>
> Regards,
> Andreas
> ------------------------------------------------------------------------------
> Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT
> is a gathering of tech-side developers & brand creativity professionals.
> Meet
> the minds behind Google Creative Lab, Visual Complexity, Processing, &
> iPhoneDevCamp as they present alongside digital heavyweights like Barbarian
> Group, R/GA, & Big Spaceship. http://p.sf.net/sfu/creativitycat-com
> _______________________________________________
> Libposix-development mailing list
> Lib...@li...
> https://lists.sourceforge.net/lists/listinfo/libposix-development
>
>

-- 
 Henrique Dante de Almeida
 hd...@gm...

Andreas Krennmair wrote:
> adds some multi-platform building support (i.e. it separates i386
> binaries from e.g. x86_64 binaries), and the other one adding my

I've tried your makefile, but I'm still unable to compile:

ld -o output-x86_64/libposix.so -shared output-x86_64/runtime.o
output-x86_64/stdio.o output-x86_64/string.o output-x86_64/init.o
output-x86_64/syscalls.o output-x86_64/_start.asm.o
output-x86_64/syscalls.asm.o
ld: i386 architecture of input file `output-x86_64/_start.asm.o' is
incompatible with i386:x86-64 output
ld: i386 architecture of input file `output-x86_64/syscalls.asm.o'
is incompatible with i386:x86-64 output

Changing nasm's options to -f elf64 gives the previous error again:

ld: output-x86_64/syscalls.asm.o: relocation R_X86_64_32 against
`kernel_vsyscall' can not be used when making a shared object;
recompile with -fPIC
output-x86_64/syscalls.asm.o: could not read symbols: Bad value

-- 
Guillermo O. «Tordek» Freschi. Programador, Escritor, Genio Maligno.
http://tordek.com.ar :: http://twitter.com/tordek
http://www.arcanopedia.com.ar - Juegos de Rol en Argentina

Hi,
On Sun, May 31, 2009 at 11:46 PM, Henrique Almeida <hd...@gm...> wrote:

>  Report bugs urgently. You may use Tracker for this:
>
>  https://sourceforge.net/tracker/?group_id=261625
>

How are patches supposed to be submitted? I have two patches ready, one
adding a Makefile that allows parallelized builds on multi-core CPUs and
adds some multi-platform building support (i.e. it separates i386 binaries
from e.g. x86_64 binaries), and the other one adding my previously submitted
string functions attributed with the BSD license and reformatted to match
the existing source formatting. So far, you can find the patches in mbox
format here:
http://synflood.at/tmp/libposix/makefile_stringfuncs.mbox

Regards,
Andreas

 While they don't answer, I was able to put you in the "editor" group.

2009/5/31 Henrique Almeida <hd...@gm...>:
>  I want to give full access to the wiki, but I have no idea how to do
> that. I'll send a message to SF.
>
> 2009/5/31 David Rocamora <dr...@gm...>:
>> Henrique,
>>
>> Can you open up the permissions on the wiki so I can create a page
>> called "function list" or what not. I think we should start with the
>> list we are describing there and have each function link to another
>> wiki page if more description is needed. The wiki seems locked down
>> now so I can't add the page myself.
>>
>> Thanks,
>> Dave
>>
>> On Thu, May 28, 2009 at 3:23 PM, Henrique Almeida <hd...@gm...> wrote:
>>>
>>>
>>> 2009/5/28 Tordek <ke...@gm...>:
>>>> Henrique Almeida wrote:
>>>>>  First of all, I hope the message reaches everyone, I'm not sure if
>>>>> the mailing list is working well, so please reply to this post if
>>>>> you've received it.
>>>>>
>>>>
>>>> Yes, it is.
>>>
>>> Nice.
>>>
>>>>>  We'll start the project with a simple task. During the project we'll
>>>>> need to mantain the list with the status of each function in the
>>>>> project (that is, if it has been implemented, tested, etc.).
>>>>
>>>> Do we have a wiki, or another place to post this to? A specific
>>>> format? (writing the full description of a function as an example
>>>> would be a great start).
>>>>
>>>> I'd strongly reccomend a wiki, to make it highly navigable
>>>> (categorizing functions per difficulty, and implementedness, for one).
>>>
>>> Yes, we definitely need a wiki. SF provides MediaWiki. I have activated it
>>> on:
>>>
>>> http://apps.sourceforge.net/mediawiki/libposix/index.php?title=Main_Page
>>>
>>> However, at some moment we'll need to provide a clean and uniform (and
>>> unique) appearance to the whole site, so we'll need to play with the CSS
>>> stuff in the wiki. Can you do this ? (btw, we'll need to setup a task
>>> management page too)
>>>
>>> At the moment, the table needs the following
>>> - function name
>>> - requirement (mandatory or the option group which it belongs)
>>> - whether it's obsolescent or not
>>> - expected difficulty
>>>
>>> The table will grow later, but let's keep it simple for now. For the
>>> functions atoi, crypt and dprintf that would be:
>>>
>>> atoi    mandatory    (not obsolescent)    easy
>>> crypt   XSI option   (not obsolescent)    medium
>>> dprintf mandatory    (not obsolescent)    hard
>>>
>>>  There's another wiki available in SF, called Wikispaces, I don't know if it
>>> would be better than MediaWiki, though, I've looked at their home page and
>>> it doesn't seem to be any docs there.
>>>
>>>>
>>>> --
>>>> Guillermo O. «Tordek» Freschi. Programador, Escritor, Genio Maligno.
>>>> http://tordek.com.ar :: http://twitter.com/tordek
>>>> http://www.arcanopedia.com.ar - Juegos de Rol en Argentina
>>>>
>>>>
>>>
>>>
>>>
>>> --
>>> Henrique Dante de Almeida
>>> hd...@gm...
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT
>>> is a gathering of tech-side developers & brand creativity professionals.
>>> Meet
>>> the minds behind Google Creative Lab, Visual Complexity, Processing, &
>>> iPhoneDevCamp as they present alongside digital heavyweights like Barbarian
>>> Group, R/GA, & Big Spaceship. http://p.sf.net/sfu/creativitycat-com
>>> _______________________________________________
>>> Libposix-development mailing list
>>> Lib...@li...
>>> https://lists.sourceforge.net/lists/listinfo/libposix-development
>>>
>>>
>>
>
>
>
> --
>  Henrique Dante de Almeida
>  hd...@gm...
>

-- 
 Henrique Dante de Almeida
 hd...@gm...

libposix-development Mailing List for libposix (Page 8)

libposix-development — This list is for those who develop or are willing to develop libposix