from:"Pierre Pronchery"

Re: Driver support for Intel I225/I226 Ethernet adapters

2023-10-10 Thread Pierre Pronchery

Hi everyone,

> On 4. Oct 2023, at 10:01, Rin Okuyama  wrote:
> 
> I've committed igc(4) driver for Intel I225 and I226 series NICs with
> one-week delay ;)
> 
> As noted in the commit log, it is still experimental; it lacks some
> logic for minor error
> handling paths, but it works almost fine for both LP64/ILP32 and
> big-/little-endian.

This is awesome, thank you!

With the netbsd-10 branch:

> [ 1.044048] ppb1 at pci0 dev 28 function 1: Intel Elkhart Lake PCIe Root 
> Port 1 (PCIe 0, Single VC) (rev. 0x11)
> [ 1.044048] ppb1: PCI Express capability version 2  Root Complex> x1 @ 8.0GT/s
> [ 1.044048] ppb1: link is x1 @ 5.0GT/s
> [ 1.044048] pci2 at ppb1 bus 2
> [ 1.044048] pci2: i/o space, memory space enabled
> [ 1.044048] igc0 at pci2 dev 0 function 0: Intel(R) Ethernet Controller 
> I226-V (rev. 0x04)
> [ 1.044048] igc0: txrx interrupting at msix3 vec 0
> [ 1.044048] igc0: txrx interrupting at msix3 vec 1
> [ 1.044048] igc0: txrx interrupting at msix3 vec 2
> [ 1.044048] igc0: txrx interrupting at msix3 vec 3
> [ 1.044048] igc0: link interrupting at msix3 vec 4
> [ 1.044048] igc0: PHY: OUI 0x984fee model 0x0005, rev. 8
> [ 1.044048] igc0: ROM image version 2.14, PHY FW version 0x8877
> [ 1.044048] igc0: Ethernet address 00:12:34:56:78:9g
> [ 1.044048] ppb2 at pci0 dev 28 function 2: Intel Elkhart Lake PCIe Root 
> Port 2 (PCIe 0, Single VC) (rev. 0x11)
> [ 1.044048] ppb2: PCI Express capability version 2  Root Complex> x1 @ 8.0GT/s
> [ 1.044048] ppb2: link is x1 @ 5.0GT/s
> [ 1.044048] pci3 at ppb2 bus 3
> [ 1.044048] pci3: i/o space, memory space enabled
> [ 1.044048] igc1 at pci3 dev 0 function 0: Intel(R) Ethernet Controller 
> I226-V (rev. 0x04)
> [ 1.044048] igc1: txrx interrupting at msix4 vec 0
> [ 1.044048] igc1: txrx interrupting at msix4 vec 1
> [ 1.044048] igc1: txrx interrupting at msix4 vec 2
> [ 1.044048] igc1: txrx interrupting at msix4 vec 3
> [ 1.044048] igc1: link interrupting at msix4 vec 4
> [ 1.044048] igc1: PHY: OUI 0x984fee model 0x0005, rev. 8
> [ 1.044048] igc1: ROM image version 2.14, PHY FW version 0x8877
> [ 1.044048] igc1: Ethernet address 00:12:34:56:78:9h


(MAC addresses amended manually)

I cannot test if the cards are functional yet - these interfaces are not 
connected to anything at the moment - but I will let you know if I run into any 
issues.

Both cards do report 2.5GBASE-T capacity in “ifconfig -m” as expected.

Cheers!
— khorben

> On Fri, Sep 22, 2023 at 9:00 PM Pierre Pronchery  wrote:
>> 
>>Hi :)
>> 
>>> On 22. Sep 2023, at 11:36, Rin Okuyama  wrote:
>>> 
>>> Sorry for the late response.
>> 
>> No worries!
>> 
>>> On Mon, Sep 18, 2023 at 6:01 AM Pierre Pronchery  wrote:
>>>> I am wondering if anyone has any plans to work on supporting Intel’s I225 
>>>> and/or I226 series of Ethernet adapters in NetBSD?
>>>> 
>>>> I have a board with a couple I226-V chips here (CW-J6-NAS, as per 
>>>> https://cwwk.net/products/j6412-j6413-nas-board-six-sata3-0-dual-m-2-i226-v-nics).
>>>>  It works great with NetBSD so far, but only the Realtek-based Ethernet 
>>>> chip is recognised.
>>>> 
>>>> I’ll be happy to test tentative drivers on request.
>>> 
>>> knakahara@,  msaitoh@, and I are working on importing igc(4) driver
>>> from OpenBSD.
>>> It already works almost fine. We will commit it next week if no
>>> serious problem appears :)
>> 
>> This is awesome to hear, thank you!
>> 
>> Looking forward to testing it,

--
khorben


signature.asc
Description: Message signed with OpenPGP

Re: W^X mmap

2016-12-26 Thread Pierre Pronchery


Hi,

I have simplified the patch, changed it to return EACCES upon errors, 
adapted it to -current, and tested it there (both with PAX_MPROTECT set 
and not set). It is still not 100% elegant though (adds an #ifdef) so I 
will welcome ideas on how to improve it some more.


Cheers,
-- khorben

On 26/12/2016 00:10, Pierre Pronchery wrote:

On 10/12/2016 14:02, Michael van Elst wrote:

co...@sdf.org writes:


Why doesn't the following code get rejected by pax mprotect?



a = mmap(NULL, BUFSIZ, PROT_READ | PROT_WRITE | PROT_EXEC,
MAP_ANON, -1, 2);


It gets 'rejected' by silently dropping the PROT_EXEC flag.


I find this awful: programs trying to use e.g JIT will fail to detect
that it really is not supported, and crash later instead.

I am attaching here a patch returning errors instead.

Thanks to this patch, www/firefox works without having to set the "m:
mprotect(2) restrictions, explicit disable" flag on its executable
binaries (tested on netbsd-7/amd64).


POSIX would require mmap to fail with errno = EACCES.


In the patch attached I have used ENOTSUP, because this is what OpenBSD
seems to be using:
http://man.openbsd.org/mmap.2

I also think EACCES (or EPERM?) would be better though, so I will be
happy to replace it if considered more appropriate.

I have changed the logic deciding which flags to drop. It used to be,
independently of whether PROT_READ is set:
- if PROT_WRITE, or PROT_WRITE and PROT_EXECUTE are set, then execution
  is silently denied;
- otherwise, writing is silently denied.
(which doesn't make much sense to me)

Now there would be only one case instead:
- if PROT_WRITE and PROT_EXECUTE are set, execution is denied and an
  error is returned.

Another thing I will really need to know before committing this, is
whether the changes should really be applied to sys_mmap() only.
Finally, I left a XXX where there might be a side-effect, if applied in
sys/kern/exec_subr.c, after calling vn_rdwr().

Cheers,


--
khorben
Index: sys/kern/kern_pax.c
===
RCS file: /cvsroot/src/sys/kern/kern_pax.c,v
retrieving revision 1.57
diff -p -u -r1.57 kern_pax.c
--- sys/kern/kern_pax.c	17 Sep 2016 02:29:11 -	1.57
+++ sys/kern/kern_pax.c	26 Dec 2016 13:25:40 -
@@ -423,7 +423,7 @@ pax_mprotect_elf_flags_active(uint32_t f
 	return true;
 }
 
-void
+int
 pax_mprotect_adjust(
 #ifdef PAX_MPROTECT_DEBUG
 const char *file, size_t line,
@@ -434,9 +434,10 @@ pax_mprotect_adjust(
 
 	flags = l->l_proc->p_pax;
 	if (!pax_flags_active(flags, P_PAX_MPROTECT))
-		return;
+		return 0;
 
-	if ((*prot & (VM_PROT_WRITE|VM_PROT_EXECUTE)) != VM_PROT_EXECUTE) {
+	if ((*prot & (VM_PROT_WRITE|VM_PROT_EXECUTE))
+			== (VM_PROT_WRITE|VM_PROT_EXECUTE)) {
 #ifdef PAX_MPROTECT_DEBUG
 		struct proc *p = l->l_proc;
 		if ((*prot & VM_PROT_EXECUTE) && pax_mprotect_debug) {
@@ -447,18 +448,10 @@ pax_mprotect_adjust(
 #endif
 		*prot &= ~VM_PROT_EXECUTE;
 		*maxprot &= ~VM_PROT_EXECUTE;
-	} else {
-#ifdef PAX_MPROTECT_DEBUG
-		struct proc *p = l->l_proc;
-		if ((*prot & VM_PROT_WRITE) && pax_mprotect_debug) {
-			printf("%s: %s,%zu: %d.%d (%s): -w\n",
-			__func__, file, line,
-			p->p_pid, l->l_lid, p->p_comm);
-		}
-#endif
-		*prot &= ~VM_PROT_WRITE;
-		*maxprot &= ~VM_PROT_WRITE;
+		return EACCES;
 	}
+
+	return 0;
 }
 
 /*
Index: sys/sys/pax.h
===
RCS file: /cvsroot/src/sys/sys/pax.h,v
retrieving revision 1.25
diff -p -u -r1.25 pax.h
--- sys/sys/pax.h	3 Sep 2016 12:20:58 -	1.25
+++ sys/sys/pax.h	26 Dec 2016 13:25:41 -
@@ -63,7 +63,7 @@ void pax_setup_elf_flags(struct exec_pac
 # define pax_setup_elf_flags(e, flags) __USE(flags)
 #endif
 
-void pax_mprotect_adjust(
+int pax_mprotect_adjust(
 #ifdef PAX_MPROTECT_DEBUG
 const char *, size_t,
 #endif
Index: sys/uvm/uvm_mmap.c
===
RCS file: /cvsroot/src/sys/uvm/uvm_mmap.c,v
retrieving revision 1.162
diff -p -u -r1.162 uvm_mmap.c
--- sys/uvm/uvm_mmap.c	9 Aug 2016 12:17:04 -	1.162
+++ sys/uvm/uvm_mmap.c	26 Dec 2016 13:25:41 -
@@ -411,7 +411,12 @@ sys_mmap(struct lwp *l, const struct sys
 		pos = 0;
 	}
 
-	PAX_MPROTECT_ADJUST(l, , );
+#ifdef PAX_MPROTECT
+	error = PAX_MPROTECT_ADJUST(l, , );
+	if (error) {
+		goto out;
+	}
+#endif
 
 	pax_aslr_mmap(l, , orig_addr, flags);
 
Index: sys/uvm/uvm_unix.c
===
RCS file: /cvsroot/src/sys/uvm/uvm_unix.c,v
retrieving revision 1.47
diff -p -u -r1.47 uvm_unix.c
--- sys/uvm/uvm_unix.c	7 Apr 2016 12:07:36 -	1.47
+++ sys/uvm/uvm_unix.c	26 Dec 2016 13:25:41 -
@@ -100,6 +100,7 @@ sys_obreak(struct lwp *l, const struct s
 		vm_prot_t prot = UVM_PROT_READ | UVM_PROT_WRITE;
 		vm_prot_t maxprot = UVM_PROT_ALL;
 
+		/* currently never fails

Re: W^X mmap

2016-12-25 Thread Pierre Pronchery


Hi,

On 10/12/2016 14:02, Michael van Elst wrote:

co...@sdf.org writes:


Why doesn't the following code get rejected by pax mprotect?



a = mmap(NULL, BUFSIZ, PROT_READ | PROT_WRITE | PROT_EXEC, MAP_ANON, 
-1, 2);


It gets 'rejected' by silently dropping the PROT_EXEC flag.


I find this awful: programs trying to use e.g JIT will fail to detect 
that it really is not supported, and crash later instead.


I am attaching here a patch returning errors instead.

Thanks to this patch, www/firefox works without having to set the "m: 
mprotect(2) restrictions, explicit disable" flag on its executable 
binaries (tested on netbsd-7/amd64).



POSIX would require mmap to fail with errno = EACCES.


In the patch attached I have used ENOTSUP, because this is what OpenBSD 
seems to be using:

http://man.openbsd.org/mmap.2

I also think EACCES (or EPERM?) would be better though, so I will be 
happy to replace it if considered more appropriate.


I have changed the logic deciding which flags to drop. It used to be, 
independently of whether PROT_READ is set:

- if PROT_WRITE, or PROT_WRITE and PROT_EXECUTE are set, then execution
  is silently denied;
- otherwise, writing is silently denied.
(which doesn't make much sense to me)

Now there would be only one case instead:
- if PROT_WRITE and PROT_EXECUTE are set, execution is denied and an
  error is returned.

Another thing I will really need to know before committing this, is 
whether the changes should really be applied to sys_mmap() only. 
Finally, I left a XXX where there might be a side-effect, if applied in 
sys/kern/exec_subr.c, after calling vn_rdwr().


Cheers,
--
khorben
diff --git a/sys/kern/exec_subr.c b/sys/kern/exec_subr.c
index efd0b5e..b523288 100644
--- a/sys/kern/exec_subr.c
+++ b/sys/kern/exec_subr.c
@@ -185,7 +185,9 @@ vmcmd_map_pagedvn(struct lwp *l, struct exec_vmcmd *cmd)
 	prot = cmd->ev_prot;
 	maxprot = UVM_PROT_ALL;
 #ifdef PAX_MPROTECT
-	pax_mprotect(l, , );
+	error = pax_mprotect(l, , );
+	if (error)
+		return error;
 #endif /* PAX_MPROTECT */
 
 	/*
@@ -267,7 +269,10 @@ vmcmd_readvn(struct lwp *l, struct exec_vmcmd *cmd)
 	prot = cmd->ev_prot;
 	maxprot = VM_PROT_ALL;
 #ifdef PAX_MPROTECT
-	pax_mprotect(l, , );
+	/* XXX side-effects with vn_rdwr()? */
+	error = pax_mprotect(l, , );
+	if (error)
+		return error;
 #endif /* PAX_MPROTECT */
 
 #ifdef PMAP_NEED_PROCWR
@@ -327,7 +332,9 @@ vmcmd_map_zero(struct lwp *l, struct exec_vmcmd *cmd)
 	prot = cmd->ev_prot;
 	maxprot = UVM_PROT_ALL;
 #ifdef PAX_MPROTECT
-	pax_mprotect(l, , );
+	error = pax_mprotect(l, , );
+	if (error)
+		return error;
 #endif /* PAX_MPROTECT */
 
 	error = uvm_map(>p_vmspace->vm_map, >ev_addr,
diff --git a/sys/kern/kern_pax.c b/sys/kern/kern_pax.c
index 2b1bc12..e84838a 100644
--- a/sys/kern/kern_pax.c
+++ b/sys/kern/kern_pax.c
@@ -263,26 +263,28 @@ pax_init(void)
 }
 
 #ifdef PAX_MPROTECT
-void
+int
 pax_mprotect(struct lwp *l, vm_prot_t *prot, vm_prot_t *maxprot)
 {
 	uint32_t f;
 
 	if (!pax_mprotect_enabled)
-		return;
+		return 0;
 
 	f = l->l_proc->p_pax;
 	if ((pax_mprotect_global && (f & ELF_NOTE_PAX_NOMPROTECT) != 0) ||
 	(!pax_mprotect_global && (f & ELF_NOTE_PAX_MPROTECT) == 0))
-		return;
+		return 0;
 
-	if ((*prot & (VM_PROT_WRITE|VM_PROT_EXECUTE)) != VM_PROT_EXECUTE) {
+	if ((*prot & (VM_PROT_WRITE|VM_PROT_EXECUTE))
+			== (VM_PROT_WRITE|VM_PROT_EXECUTE)) {
 		*prot &= ~VM_PROT_EXECUTE;
 		*maxprot &= ~VM_PROT_EXECUTE;
-	} else {
-		*prot &= ~VM_PROT_WRITE;
-		*maxprot &= ~VM_PROT_WRITE;
+		log(LOG_ALERT, "PaX MPROTECT: [%d] Enforcing W^X\n",
+			l->l_proc->p_pid);
+		return ENOTSUP;
 	}
+	return 0;
 }
 #endif /* PAX_MPROTECT */
 
diff --git a/sys/sys/pax.h b/sys/sys/pax.h
index 0c28b46..e8b1d13 100644
--- a/sys/sys/pax.h
+++ b/sys/sys/pax.h
@@ -47,7 +47,7 @@ struct vmspace;
 
 void pax_init(void);
 
-void pax_mprotect(struct lwp *, vm_prot_t *, vm_prot_t *);
+int pax_mprotect(struct lwp *, vm_prot_t *, vm_prot_t *);
 int pax_segvguard(struct lwp *, struct vnode *, const char *, bool);
 
 #define	PAX_ASLR_DELTA(delta, lsb, len)	\
diff --git a/sys/uvm/uvm_mmap.c b/sys/uvm/uvm_mmap.c
index 8043f0f..5291ab5 100644
--- a/sys/uvm/uvm_mmap.c
+++ b/sys/uvm/uvm_mmap.c
@@ -416,7 +416,10 @@ sys_mmap(struct lwp *l, const struct sys_mmap_args *uap, register_t *retval)
 	}
 
 #ifdef PAX_MPROTECT
-	pax_mprotect(l, , );
+	error = pax_mprotect(l, , );
+	if (error) {
+		goto out;
+	}
 #endif /* PAX_MPROTECT */
 
 #ifdef PAX_ASLR
diff --git a/sys/uvm/uvm_unix.c b/sys/uvm/uvm_unix.c
index 7ac5579..b6d1c7e 100644
--- a/sys/uvm/uvm_unix.c
+++ b/sys/uvm/uvm_unix.c
@@ -103,7 +103,11 @@ sys_obreak(struct lwp *l, const struct sys_obreak_args *uap, register_t *retval)
 		vm_prot_t maxprot = UVM_PROT_ALL;
 
 #ifdef PAX_MPROTECT
-		pax_mprotect(l, , );
+		error = pax_mprotect(l, , );
+		if (error) {
+			mutex_exit(>p_auxlock);
+			return (error);
+		}
 #endif /* PAX_MPROTECT */
 
 		error = uvm_map(>vm_map, , new - old, NULL,

Re: gmake segfaults with netbsd32 compat

2016-09-15 Thread Pierre Pronchery


Hey there,

On 15/09/2016 21:04, co...@sdf.org wrote:

On Thu, Sep 15, 2016 at 06:27:01PM +0200, Pierre Pronchery wrote:

On 09/15/16 08:44 AM, co...@sdf.org wrote:

building with everything i386 except amd64 kernel or in i386 chroot and
amd64 host I have gmake repeatedly segfaulting. so much that I resorted
to using `while true; do make install; done` to get through building
packages.

I don't recall having such trouble with all i386 and switching back to
it seems to help a lot.

anyone seeing the same?


Are you using PaX mprotect? Try to "paxctl +m gmake" just in case.


Seems to be doing much better after
   paxctl +a `which gmake`


Right, it's an issue with ASLR not mprotect; I mis-remembered.


Interesting it works well on i386, works well on amd64, but not in amd64
kernel with i386 userland.

When I looked around, I noticed it is making calls like
remake.c:319-320

   /* Clean up any alloca() used during the update.  */
   alloca (0);

The Internet told me "don't do that". Would that be possibly related?


No, the underlying issue is documented there:
http://gnats.netbsd.org/cgi-bin/query-pr-single.pl?number=50469

I committed a fix to -current (with help from xtos@) and asked for a 
pull-up to NetBSD 7 but martin@ thinks the fix is not correct. He knows 
better so I did not insist after that.


It works just fine in EdgeBSD though :)

HTH,
--
khorben

Re: (almost) full disk encryption, cgdroot and firmware

2016-06-22 Thread Pierre Pronchery


Hey,

On 06/20/16 21:15, Alexander Nasonov wrote:

This is my story on (almost) full disk encryption.

I followed Pierre Proncher's instruction from Mar 2013. To my
surprise, it worked on the first boot. However, networking didn't


Glad to hear :)


work because the kernel couldn't load iwm firmware.


Indeed, there are issues when loading firmware. In any case, I have 
(finally!) created a wiki page to summarize the current situation:

https://wiki.netbsd.org/security/cgdroot/

HTH,
--
khorben

Re: PaX mprotect now on for amd64

2016-05-26 Thread Pierre Pronchery


Hi all,

On 05/22/16 16:44, Thomas Klausner wrote:

On Thu, May 19, 2016 at 05:42:55PM +0200, Pierre Pronchery wrote:

I wrote this mini-framework for paxctl(8) in pkgsrc:

http://git.edgebsd.org/gitweb/?p=edgebsd-pkgsrc.git;a=commitdiff;h=f1354300f9d734202bd0ce49b33d74f455aea9e1

and addressed some concerns there:
http://git.edgebsd.org/gitweb/?p=edgebsd-pkgsrc.git;a=commitdiff;h=4ed2e62c4e7416abbf6eba9887cdc5e2c6997c67

Let me know if I should import it, or about any concerns.


I don't like the variable names, since they do not provide a hint that
they are lists of file names, but I don't have a concrete better
proposal.


We can change this later if something better crosses our minds.


Please commit this so we can start tagging java with it...


Done!

--
khorben

Re: PaX mprotect now on for amd64

2016-05-19 Thread Pierre Pronchery


On 05/15/16 10:22, David Brownlee wrote:

On 14 May 2016 at 18:09, Christos Zoulas  wrote:

I just turned on mprotect for amd64. The following sysctls have
been set to 1

security.pax.mprotect.enable=1
security.pax.mprotect.global=1
[...]
This breaks programs that need to map segments both writable and executable,
for example java. To fix them you can:

paxctl +m /path/to/bin/java

[...]
Would it make sense to (possibly optionally) integrate this into
pkgsrc builds for at least java? (the paxctl +m call)


I wrote this mini-framework for paxctl(8) in pkgsrc:

http://git.edgebsd.org/gitweb/?p=edgebsd-pkgsrc.git;a=commitdiff;h=f1354300f9d734202bd0ce49b33d74f455aea9e1

and addressed some concerns there:
http://git.edgebsd.org/gitweb/?p=edgebsd-pkgsrc.git;a=commitdiff;h=4ed2e62c4e7416abbf6eba9887cdc5e2c6997c67

Let me know if I should import it, or about any concerns.

Cheers,
--
khorben

Re: amd64/7.0_BETA fails to probe USB devices?

2015-04-29 Thread Pierre Pronchery

Hi Havard,

On 04/28/15 16:05, Havard Eidnes wrote:
 I've recently been installing NetBSD on a new Lenovo RD350
 server.  I first tried booting from USB disk and from a USB
 CD-ROM drive, and both the install kernels loaded just fine.
 However, the boot medium was not probed by the 7.0_BETA amd64
 kernel. [...]
 
 Anyone else seeing something similar, or is this particular to
 this chipset combination?  Anything I can do to debug this
 further?

This is PR kern/48494 :(

As a workaround you can boot with -2 (disable ACPI).

HTH,
-- 
khorben

Updating SQLite to 3.8.9

2015-04-15 Thread Pierre Pronchery


Hi there,

a new version of SQLite is now available, 3.8.9:
http://sqlite.org/releaselog/3_8_9.html

Upgrading is recommended (http://sqlite.org/).

Reading this blog post from lcamtuf, it does seems quite important to 
update indeed:

http://lcamtuf.blogspot.de/2015/04/finding-bugs-in-sqlite-easy-way.html

He found a number of crashes, some potentially security-critical 
(depending on the way the software is used). Even though there was no 
security advisory published to date, the new release fixes every issue 
found.


HTH,
--
khorben

Re: a separate build of libc

2014-10-09 Thread Pierre Pronchery

Hi there,

On 29/09/2014 16:18, u-6...@aetey.se wrote:
 On Mon, Sep 29, 2014 at 02:34:46PM +0200, Pierre Pronchery wrote:
 I'm considering re-licensing the whole DeforaOS project under BSD.
 You're not the first person to mention this to me, so I guess I'll just
 stop wasting time and do it.
 
 That would be definitely a nice move and make the library and the
 whole project attractive for many more users.
 
 I would say go ahead Pierre.

It's out there now:
http://www.defora.org/os/news/4333/BSD-licensed%20releases%20of%20configure%20and%20libc

Direct link:
http://www.defora.org/os/download/download/4332/libc-0.1.0.tar.gz

(I have some issues with the downloads being doubly gzip-compressed with
some browsers on www.defora.org, so do not panic if it does not extract
right away; I am investigating...)

HTH,
-- 
khorben

Re: a separate build of libc

2014-09-29 Thread Pierre Pronchery

Hi Rune,

I do not have the time to read the entire thread now, but you may want
to check the DeforaOS libc, which supports NetBSD (and Linux (and
more)). You can find it there:

http://www.defora.org/os/project/14/libc
http://git.defora.org/gitweb/?p=libc.git;a=summary
(or git clone http://git.defora.org/DeforaOS/libc.git)

Let me know if you need any help with it.

HTH,
-- khorben

On 19/09/2014 16:04, u-6...@aetey.se wrote:
 Background:
 
   building an independent/standalone toolchain able to produce binaries
   runnable on NetBSD
   (note, this is not the same as compiling or cross-compiling NetBSD)
 
 The component:
 
   libc
 
 A small practical question:
 
   Where does machine/asm.h come from, given the NetBSD source sets as
   the starting point?
 
 Presumably it is possible to find out the answer by analysing the
 build.sh tool but the named tool is possibly not the (only) definition
 of the structure/interrelations of the concerned data?
 
 A deeper question:
 
   What would be the minimal initial data (source) to be able to recreate
   a working NetBSD libc? I get the impression that the data is widely
   scattered across different file trees and source sets, my goal
   is now to identify the relevant subset of the whole.
 
 To better describe what I have in mind, I might refer to the source archive
 of musl Linux libc, which includes everything (including all includes :)
 that is needed for the build, as a single archive of less than 1MB.
 The compiler and linker to be used do not have to be platform-specific
 beyond the capability to build executables in a format understandable
 by the target kernel.
 
 I don't see that there is any similar abstraction for NetBSD libc yet (?).
 It would be pretty useful.
 
 Anybody who can/would answer the questions above?
 
 Regards,
 Rune

-- 
khorben

Re: a separate build of libc

2014-09-29 Thread Pierre Pronchery

On 29/09/2014 13:05, u-6...@aetey.se wrote:
 On Mon, Sep 29, 2014 at 12:14:42PM +0200, Pierre Pronchery wrote:
 I do not have the time to read the entire thread now, but you may want
 to check the DeforaOS libc, which supports NetBSD (and Linux (and
 more)). You can find it there:

 http://www.defora.org/os/project/14/libc
 http://git.defora.org/gitweb/?p=libc.git;a=summary
 (or git clone http://git.defora.org/DeforaOS/libc.git)
 
 Oh nice.
 
 Unfortunately one thing which makes me less entusiastic is the non-BSD
 license, GPL for a libc is pretty intrusive, not even the GNU libc
 uses it.

I'm considering re-licensing the whole DeforaOS project under BSD.
You're not the first person to mention this to me, so I guess I'll just
stop wasting time and do it.

Cheers,
-- 
khorben

Re: Driver support for Intel I225/I226 Ethernet adapters

Re: W^X mmap

Re: W^X mmap

Re: gmake segfaults with netbsd32 compat

Re: (almost) full disk encryption, cgdroot and firmware

Re: PaX mprotect now on for amd64

Re: PaX mprotect now on for amd64

Re: amd64/7.0_BETA fails to probe USB devices?

Updating SQLite to 3.8.9

Re: a separate build of libc

Re: a separate build of libc

Re: a separate build of libc

12 matches

Site Navigation

Mail list logo

Footer information