Re: sqlite/Heimdal.

On Thu, Mar 31, 2011 at 09:56:00AM +0100, Roland C. Dowdeswell wrote:
> I am in the process of upgrading Heimdal in base.  It turns out
> that Heimdal now requires sqlite3 and includes its own version of
> same.  I think that it would be more general utility to import
> sqlite3 independently, though, and would like to start a discussion
> about doing it.
> 
> The license on sqlite3 is public domain.
> 
> It has no dependencies beyond -lc and -lphtread.  The package is
> one (rather large) C file, two headers and some autoconf goo only.
> And so it should be relatively easy to maintain and upgrade.
> 
> More information about sqlite3 can be found at http://sqlite.org/

+1 importing sqlite3

I've always liked sqlite and I've been doing a lot of development with it
lately at work and it is just a very nice product (and well tested, too!). 
While it is designed as an embedded database, I think it is strong enough to
take care of the vast majority of database needs (i.e., not many need the 
added benefits of a Postgres or the like).

--

-- 
Christopher Berardi
http://www.natoufa.com/

Be still, and know that I am God (Psalms 46:10)

Re: sqlite/Heimdal.

In article <20110401002956.GA8906 <at> natoufa>,
Christopher Berardi  <cberardi <at> natoufa.com> wrote:
>On Thu, Mar 31, 2011 at 09:56:00AM +0100, Roland C. Dowdeswell wrote:
>> I am in the process of upgrading Heimdal in base.  It turns out
>> that Heimdal now requires sqlite3 and includes its own version of
>> same.  I think that it would be more general utility to import
>> sqlite3 independently, though, and would like to start a discussion
>> about doing it.
>> 
>> The license on sqlite3 is public domain.
>> 
>> It has no dependencies beyond -lc and -lphtread.  The package is
>> one (rather large) C file, two headers and some autoconf goo only.
>> And so it should be relatively easy to maintain and upgrade.
>> 
>> More information about sqlite3 can be found at http://sqlite.org/
>
>+1 importing sqlite3

+1 for importing sqlite3!

christos

Re: sqlite/Heimdal.

On Fri, Apr 01, 2011 at 02:02:34AM +0000, Christos Zoulas wrote:
> In article <20110401002956.GA8906 <at> natoufa>,
> Christopher Berardi  <cberardi <at> natoufa.com> wrote:
> >On Thu, Mar 31, 2011 at 09:56:00AM +0100, Roland C. Dowdeswell wrote:
> >> I am in the process of upgrading Heimdal in base.  It turns out
> >> that Heimdal now requires sqlite3 and includes its own version of
> >> same.  I think that it would be more general utility to import
> >> sqlite3 independently, though, and would like to start a discussion
> >> about doing it.
> >> 
> >> The license on sqlite3 is public domain.
> >> 
> >> It has no dependencies beyond -lc and -lphtread.  The package is
> >> one (rather large) C file, two headers and some autoconf goo only.
> >> And so it should be relatively easy to maintain and upgrade.
> >> 
> >> More information about sqlite3 can be found at http://sqlite.org/
> >
> >+1 importing sqlite3
> 
> +1 for importing sqlite3!

+1 for stamping out "me too" emails!

Having said that, I'd also like to see sqlite3 imported into base,
with options rtree, fts and ucs enabled by default.

Best,
Alistair

xen-kernel boot fix: AT&T vs. GNU od(1)

Hi,

I submitted the fix to xen-devel <at>  that makes the xen kernel boot.
I got this response:

On 03/31/11 20:29, Ian Jackson wrote:
> Christoph Egger writes ("[Xen-devel] [PATCH] xen: fix reloc.S
generation"):
>> attached patch fixes generation of reloc.S and makes
>> xen boot out-of-the box since c/s 19146.
>> The output of AT&T UNIX and GNU od(1) are different.
>
> Which (if any) of these versions of od is correct ? The SuSv3
> specification of od is quite comprehensive so it should be possible to
> contrive a rune which doesn't need subsequent seddery. Could you try
> to do so ?

Christoph

Re: xen-kernel boot fix: AT&T vs. GNU od(1)

On 04/01/11 11:46, Christoph Egger wrote:
>
> Hi,
>
> I submitted the fix to xen-devel <at>  that makes the xen kernel boot.
> I got this response:

Sorry, I forgot the patch.

Christoph

> On 03/31/11 20:29, Ian Jackson wrote:
>> Christoph Egger writes ("[Xen-devel] [PATCH] xen: fix reloc.S
> generation"):
>>> attached patch fixes generation of reloc.S and makes
>>> xen boot out-of-the box since c/s 19146.
>>> The output of AT&T UNIX and GNU od(1) are different.
>>
>> Which (if any) of these versions of od is correct ? The SuSv3
>> specification of od is quite comprehensive so it should be possible to
>> contrive a rune which doesn't need subsequent seddery. Could you try
>> to do so ?
>
> Christoph

diff -r cebd5d3f0ec4 xen/arch/x86/boot/build32.mk
--- a/xen/arch/x86/boot/build32.mk	Fri Mar 25 11:29:24 2011 +0100
+++ b/xen/arch/x86/boot/build32.mk	Thu Mar 31 12:13:22 2011 +0200

Re: xen-kernel boot fix: AT&T vs. GNU od(1)

On 04/01/11 13:18, Christoph Egger wrote:
> On 04/01/11 11:46, Christoph Egger wrote:
>>
>> Hi,
>>
>> I submitted the fix to xen-devel <at>  that makes the xen kernel boot.
>> I got this response:
>
> Sorry, I forgot the patch.

I attached the reloc.bin which is the input.

This is what the build system does to generate the reloc.S:

(od -v -t x reloc.bin | awk 'NR > 1 {print s} {s=$0}' | \
         sed 's/ /,0x/g' | sed 's/^[0-9]*,/ .long /') >reloc.S

The attached reloc.S.atandt is the result with AT&T od(1)
The attached reloc.S is the result with GNU od(1) - and what is expected.

The xen_boot.diff changes above reloc.S generation to produce
the same output with both AT&T and GNU od(1).

Christoph

>> On 03/31/11 20:29, Ian Jackson wrote:
>>> Christoph Egger writes ("[Xen-devel] [PATCH] xen: fix reloc.S
>> generation"):
>>>> attached patch fixes generation of reloc.S and makes
>>>> xen boot out-of-the box since c/s 19146.

Re: Fwd: GSoC Project: Replacement for Apropos

On Wed, Mar 30, 2011 at 8:51 PM, Joerg Sonnenberger
<joerg <at> britannica.bec.de> wrote:

>> Also, I will be having my semester exams at the end of May so I will
>> not be available for around 10 days, will that be a problem ?
>
> Officially, work phase for the GSoC starts on May 24. Starting before
> that isn't really an issue. E.g. if "not available" means "completely
> vanishing from the world", that's going to ring some warning bells.
> Having a light week, especially if the prepation phase went well, isn't
> an issue though. We all know about the importance of exams. Mentors also
> have sometimes events that demand attention, but we have the advantage
> of being able to distribute the load :)
>
> Joerg
>

Hi,

I have put up the proposal on GSoC website. I would appreciate
feedback, so that I can improve it.

Here is the link:
http://www.google-melange.com/gsoc/proposal/review/google/gsoc2011/abhinav_upadhyay/1#

I personally feel that perhaps more details are required ? But it is
too long and I already cut short on a lot of stuff. But I tried to
answer as many questions as I could from the NetBSD SoC Application
guideline (http://www.netbsd.org/contrib/soc-application.html)

Re: sqlite/Heimdal.

On Thu, Mar 31, 2011 at 2:26 PM, Roland C. Dowdeswell <elric <at> imrryr.org> wrote:
> I am in the process of upgrading Heimdal in base.  It turns out
> that Heimdal now requires sqlite3 and includes its own version of
> same.  I think that it would be more general utility to import
> sqlite3 independently, though, and would like to start a discussion
> about doing it.
>
> The license on sqlite3 is public domain.
>
> It has no dependencies beyond -lc and -lphtread.  The package is
> one (rather large) C file, two headers and some autoconf goo only.
> And so it should be relatively easy to maintain and upgrade.
>
> More information about sqlite3 can be found at http://sqlite.org/
>
> --
>    Roland Dowdeswell                      http://Imrryr.ORG/~elric/
>

Sqlite3 with FTS support enabled is required for one of the GSoC projects.

+1 for this.

--
Abhinav

undefined reference to `pqueue_size', net/freeradius not building rlm_eap_tls

Supposedly after applyin the fix fot SA2010-011, net/freeradius refuses to build most modules due to
OpenSSL not found.

There's a strange failure in config.log I can't make much sense out of:

configure:21465: checking for SSL_new in -lssl
configure:21500: cc -o conftest -O2 -I/usr/pkg/include -DLDAP_DEPRECATED -I/usr/include
-D_REENTRANT -D_POSIX_PTHREAD_SEMANTICS -I/usr/pkg/include -DLDAP_DEPRECATED -I/usr/include
-L/usr/pkg/lib -Wl,-R/usr/pkg/lib -L/usr/lib -Wl,-R/usr/lib conftest.c -lssl -lcrypto  -lcrypto
-lresolv   -pthread  >&5
/usr/lib/libssl.so: undefined reference to `pqueue_size'

I'm on 4.0.1/amd64 in case that matters.

I'm not subscribed to tech-userlevel, so please CC me if answering only there.

Re: ld.elf_so locking

On Mon, Mar 14, 2011 at 04:37:21PM +0100, Joerg Sonnenberger wrote:

> Comments?

Only a few right now..

> There are currently two situations left where a recursion would currently
> result in a dead lock: a signal handler or constructor using __tls_get_addr
> requiring memory allocation when already in ld.elf_so and a signal
> handler occuring during exclusively locked calls like dlopen trying to
> access a shared lock e.g. to lazily resolve a relocation.
> 
> The second can be mostly be adressed by using sigprocmask in the

For stuff like that one idea is to have the signal mask directly in the
_lwp_ctl area, so that sigprocmask() isn't any kind of performance concern. 
The signal mask is thread private state in the kernel with a couple of
exceptions, Oe can be worked around and I think the other relates to SA (and
so can die).  As a perhipheral benefit this could be a nice boost to some
workloads since sigprocmask() is called a lot.

On a related note is there a thread-private area that we can reserve to
point to the _lwp_ctl block?

> +static volatile bool _rtld_mutex_may_recurse;
> +

Prefer "int" or sigatomic_t as bool may be sub-word sized and thus cause
atomicity problems.  Maybe this is not a concern (although volatile
suggests it is).