On Sun, Jul 28, 2019 at 02:18:14 -0400, Michael wrote:
> On Sat, 27 Jul 2019 21:35:04 +0200
> Joerg Sonnenberger wrote:
>
> > On Fri, Jul 26, 2019 at 07:54:15AM -0300, Jared McNeill wrote:
> > > On Fri, 26 Jul 2019, Rin Okuyama wrote:
> > >
> > > > Also, convert loop of byte-wise copy into
Hello,
On Sat, 27 Jul 2019 21:35:04 +0200
Joerg Sonnenberger wrote:
> On Fri, Jul 26, 2019 at 07:54:15AM -0300, Jared McNeill wrote:
> > On Fri, 26 Jul 2019, Rin Okuyama wrote:
> >
> > > Also, convert loop of byte-wise copy into memset.
> >
> > I am a bit concerned about this change
This part has already been reverted:
http://cvsweb.netbsd.org/bsdweb.cgi/src/sys/dev/rasops/rasops.c#rev1.92
IMO, the fail-safe alternate is preferable over tiny optimization and
simplification with possible dangers.
Thanks,
rin
On 2019/07/28 4:35, Joerg Sonnenberger wrote:
On Fri, Jul 26,
Thank you for pointing it out! I didn't know that.
I will revert this part soon.
rin
On 2019/07/26 19:54, Jared McNeill wrote:
On Fri, 26 Jul 2019, Rin Okuyama wrote:
Also, convert loop of byte-wise copy into memset.
I am a bit concerned about this change because IIRC there are platforms
On Fri, 26 Jul 2019, Rin Okuyama wrote:
Also, convert loop of byte-wise copy into memset.
I am a bit concerned about this change because IIRC there are platforms
where memset etc. cannot be used on device memory.
Hi,
O.k.
I will commit your fix later.
Thank you.
Yorick Hardy writes:
> Dear Ryo,
>
> On 2019-07-25, Ryo ONODERA wrote:
>> Hi,
>>
>> Yorick Hardy writes:
>>
>> > Dear Ryo,
>> >
>> > On 2019-07-09, Ryo ONODERA wrote:
>> >> Module Name: src
>> >> Committed By: ryoon
>> >> Date:
Dear Ryo,
On 2019-07-25, Ryo ONODERA wrote:
> Hi,
>
> Yorick Hardy writes:
>
> > Dear Ryo,
> >
> > On 2019-07-09, Ryo ONODERA wrote:
> >> Module Name: src
> >> Committed By: ryoon
> >> Date: Tue Jul 9 12:52:51 UTC 2019
> >>
> >> Modified Files:
> >>
Hi,
Yorick Hardy writes:
> Dear Ryo,
>
> On 2019-07-09, Ryo ONODERA wrote:
>> Module Name: src
>> Committed By:ryoon
>> Date:Tue Jul 9 12:52:51 UTC 2019
>>
>> Modified Files:
>> src/sys/dev/hid: hidms.c hidms.h
>> src/sys/dev/i2c: ims.c
>>
>> Log Message:
>>
Dear Ryo,
On 2019-07-09, Ryo ONODERA wrote:
> Module Name: src
> Committed By: ryoon
> Date: Tue Jul 9 12:52:51 UTC 2019
>
> Modified Files:
> src/sys/dev/hid: hidms.c hidms.h
> src/sys/dev/i2c: ims.c
>
> Log Message:
> Add tpcalib, touch panel calibration to ims(4)
>
>
On 24/07/2019 06:45, SAITOH Masanobu wrote:
[snip]
@@ -27,7 +27,7 @@
/* CMD52 arguments */
#define SD_ARG_CMD52_READ (0<<31)
-#define SD_ARG_CMD52_WRITE (1<<31)
+#define SD_ARG_CMD52_WRITE (1UL<<31)
#define SD_ARG_CMD52_FUNC_SHIFT 28
On Tue, Jul 23, 2019 at 10:13:38AM -0700, Jason Thorpe wrote:
> > On Jul 23, 2019, at 10:07 AM, Jason Thorpe wrote:
> >
> >
> >
> >> On Jul 23, 2019, at 9:14 AM, Rin Okuyama wrote:
> >>
> >> Ah, you are right. We leaks uninitialized memory via mmap.
> >>
> >> However, I'm not sure that it
> On Jul 23, 2019, at 10:07 AM, Jason Thorpe wrote:
>
>
>
>> On Jul 23, 2019, at 9:14 AM, Rin Okuyama wrote:
>>
>> Ah, you are right. We leaks uninitialized memory via mmap.
>>
>> However, I'm not sure that it is safe to write DMA buffer
>> above sc->sc_vramsize after bus_dmamap_load?
>>
> On Jul 23, 2019, at 9:14 AM, Rin Okuyama wrote:
>
> Ah, you are right. We leaks uninitialized memory via mmap.
>
> However, I'm not sure that it is safe to write DMA buffer
> above sc->sc_vramsize after bus_dmamap_load?
>
> Thoughts, ARM experts?
Since fundamental memory allocation is
Ah, you are right. We leaks uninitialized memory via mmap.
However, I'm not sure that it is safe to write DMA buffer
above sc->sc_vramsize after bus_dmamap_load?
Thoughts, ARM experts?
Thanks,
rin
On 2019/07/24 0:22, m...@netbsd.org wrote:
I think we might be leaking uninitialized kernel
I think we might be leaking uninitialized kernel memory.
in tifb,
if (bus_dmamem_alloc(sc->sc_dmat, sc->sc_vramsize, 0, 0,
sc->sc_dmamem, 1, , BUS_DMA_NOWAIT) != 0) {
bus_dma* rounds up to PAGE_SIZE chunks.
memset((void *)sc->sc_vramaddr, 0, sc->sc_vramsize);
We
Can you add printfs in these two functions to dump 'bLength'?
I've reverted the change for now. I found these bugs a week ago while
manually crafting incorrect USB packets in Qemu's USB driver. It caused
memory corruptions in the NetBSD guest, which were detected by KASAN.
Fixing the length
On Fri, Jun 28, 2019 at 1:57 AM matthew green wrote:
>
> Module Name:src
> Committed By: mrg
> Date: Fri Jun 28 01:57:43 UTC 2019
>
> Modified Files:
> src/sys/dev/usb: if_axen.c if_cdce.c if_ure.c
>
> Log Message:
> more smp cleanup for ure(4)/axen(4)/cdce(4):
Thank you
Mmh no I see, the min descriptor length check we should add is 3 bytes, and my
check should be moved below in the idesc branch. I'll re-fix that next week.
Le 06/07/2019 à 10:04, Maxime Villard a écrit :
Can you add printfs in these two functions to dump 'bLength'?
I've reverted the change
It could be a coincidence, but with yesterday's kernel my
non-malicious USB keyboard (Cherry G230) worked and today it doesn't.
-uhidev0 at uhub5 port 1 configuration 1 interface 0
-uhidev0: vendor 046a (0x46a) product 0023 (0x23), rev 2.00/2.20, addr 1,
iclass 3/1
-ukbd0 at uhidev0: 8 Variable
On Fri, Jul 05, 2019 at 10:25:50PM +0200, Thomas Klausner wrote:
> On Wed, Jul 03, 2019 at 10:56:09PM +, m...@netbsd.org wrote:
> > On Wed, Jul 03, 2019 at 08:47:22PM +, Thomas Klausner wrote:
> > > Module Name: src
> > > Committed By: wiz
> > > Date: Wed Jul 3
On Wed, Jul 03, 2019 at 08:47:22PM +, Thomas Klausner wrote:
> Module Name: src
> Committed By: wiz
> Date: Wed Jul 3 20:47:22 UTC 2019
>
> Modified Files:
> src/sys/external/bsd/drm2/nouveau: nouveau_pci.c
>
> Log Message:
> Improve nouveau pci attachment code so it waits
Awesome, Jared - many thanks for this!
On Fri, 28 Jun 2019 at 08:08, Jared D. McNeill wrote:
> Module Name:src
> Committed By: jmcneill
> Date: Fri Jun 28 15:08:47 UTC 2019
>
> Modified Files:
> src/sys/dev/ic: nvme.c nvmevar.h
>
> Log Message:
> Fix a performance issue
> On Jun 29, 2019, at 2:29 AM, Maxime Villard wrote:
[...]
> Ah because now I should teach people C programming?
No, but you should be helpful and assume that the people working on this
project are not trying to annoy you or ignore you. If would have been
better to explain what the bugs are,
Le 29/06/2019 à 02:12, Hisashi T Fujinaka a écrit :
On Thu, 27 Jun 2019, Maxime Villard wrote:
Le 27/06/2019 ? 20:56, Christos Zoulas a ?crit :
On Jun 27, 8:30pm, m...@m00nbsd.net (Maxime Villard) wrote:
-- Subject: Re: CVS commit: src/sys/kern
| Le 27/06/2019 ? 19:07, Christos Zoulas
On Thu, 27 Jun 2019, Maxime Villard wrote:
Le 27/06/2019 ? 20:56, Christos Zoulas a ?crit :
On Jun 27, 8:30pm, m...@m00nbsd.net (Maxime Villard) wrote:
-- Subject: Re: CVS commit: src/sys/kern
| Le 27/06/2019 ? 19:07, Christos Zoulas a ??crit? :
| > Module Name: src
| > Com
In article ,
Maxime Villard wrote:
>
>This isn't correct, with USER_LDT the 32bit LWPs may have non-default segregs,
>besides it is really dumb to mix 32 and 64bit code, part of the reasons why
>I dropped the thing
Yes, it is still missing the check that the compat_netbsd32 function had.
On Fri, Jun 28, 2019 at 05:03:37AM -0700, Jason Thorpe wrote:
>
> > On Jun 26, 2019, at 7:10 PM, matthew green wrote:
> >
> >> Always include the 32 bit structure and definitions on _LP64 regardless
> >> of compat32 being on or off, because we want the headers to work when
> >> compiling
> On Jun 26, 2019, at 7:10 PM, matthew green wrote:
>
>> Always include the 32 bit structure and definitions on _LP64 regardless
>> of compat32 being on or off, because we want the headers to work when
>> compiling modular kernels. Of course the 32 bit structs do not make sense
>> on platforms
On Fri, Jun 28, 2019 at 06:43:45AM +1000, matthew green wrote:
> "Maxime Villard" writes:
> > Module Name:src
> > Committed By: maxv
> > Date: Thu Jun 27 19:56:10 UTC 2019
> >
> > Modified Files:
> > src/sys/kern: kern_exec.c
> >
> > Log Message:
> > Fix this
Le 27/06/2019 à 20:56, Christos Zoulas a écrit :
On Jun 27, 8:30pm, m...@m00nbsd.net (Maxime Villard) wrote:
-- Subject: Re: CVS commit: src/sys/kern
| Le 27/06/2019 à 19:07, Christos Zoulas a écrit :
| > Module Name: src
| > Committed By:christos
| > Date:Thu
Le 27/06/2019 à 21:56, Maxime Villard a écrit :
Module Name:src
Committed By: maxv
Date: Thu Jun 27 19:56:10 UTC 2019
Modified Files:
src/sys/kern: kern_exec.c
Log Message:
Fix this fucking shit once and for all, for fuck's sake.
To generate a diff of this commit:
cvs
In article <20190627195610.c4be7f...@cvs.netbsd.org>,
Maxime Villard wrote:
>-=-=-=-=-=-
>
>Module Name: src
>Committed By: maxv
>Date: Thu Jun 27 19:56:10 UTC 2019
>
>Modified Files:
> src/sys/kern: kern_exec.c
>
>Log Message:
>Fix this fucking shit once and for all, for fuck's
On Jun 27, 9:26pm, m...@m00nbsd.net (Maxime Villard) wrote:
-- Subject: Re: CVS commit: src/sys/kern
| > I don't know, is this the most efficient way to communicate it if I did?
|
| This got to be a fucking joke.
Well, you know the bug, and I think it is more valuable for me to
spend t
> Always include the 32 bit structure and definitions on _LP64 regardless
> of compat32 being on or off, because we want the headers to work when
> compiling modular kernels. Of course the 32 bit structs do not make sense
> on platforms that don't have 32 bit modes (alpha), but we don't have
> a
On Jun 27, 8:30pm, m...@m00nbsd.net (Maxime Villard) wrote:
-- Subject: Re: CVS commit: src/sys/kern
| Le 27/06/2019 à 19:07, Christos Zoulas a écrit :
| > Module Name:src
| > Committed By: christos
| > Date: Thu Jun 27 17:07:51 UTC 2019
| >
| >
Le 27/06/2019 à 19:07, Christos Zoulas a écrit :
Module Name:src
Committed By: christos
Date: Thu Jun 27 17:07:51 UTC 2019
Modified Files:
src/sys/kern: kern_exec.c
Log Message:
Return an error if the path was too long. Pointed out by maxv
To generate a diff of this
Le 26/06/2019 à 23:21, Christos Zoulas a écrit :
In article <20190626202859.b5ccef...@cvs.netbsd.org>,
Maxime Villard wrote:
-=-=-=-=-=-
Module Name:src
Committed By: maxv
Date: Wed Jun 26 20:28:59 UTC 2019
Modified Files:
src/sys/kern: kern_exec.c
Log Message:
On Jun 27, 6:59pm, m...@m00nbsd.net (Maxime Villard) wrote:
-- Subject: Re: CVS commit: src/sys/kern
| Yet it seems pretty obvious to me. As you explained in the comment, the
| function is supposed to return an absolute path. Here, however, it does
| not return an absolute path
Le 27/06/2019 à 04:00, Christos Zoulas a écrit :
Module Name:src
Committed By: christos
Date: Thu Jun 27 02:00:31 UTC 2019
Modified Files:
src/sys/arch/amd64/amd64: machdep.c
Log Message:
Although this is correct, I will let maxv commit it. Still waiting.
To generate
Le 26/06/2019 à 22:33, Christos Zoulas a écrit :
On Jun 26, 10:30pm, m...@m00nbsd.net (Maxime Villard) wrote:
-- Subject: Re: CVS commit: src/sys/kern
| Le 25/06/2019 à 23:32, Christos Zoulas a écrit :
| > Module Name: src
| > Committed By:christos
| > Date:Tue
On 2019/06/27 18:56, SAITOH Masanobu wrote:
> Module Name: src
> Committed By: msaitoh
> Date: Thu Jun 27 09:56:39 UTC 2019
>
> Modified Files:
> src/sys/dev/pci/ixgbe: ixv.c
>
> Log Message:
> Don't call set_vfta() if any VLAN is attached.
s/is/is not/
> XXX pullup-8.
>
>
>
On 26.06.2019 23:21, Christos Zoulas wrote:
> In article <20190626202859.b5ccef...@cvs.netbsd.org>,
> Maxime Villard wrote:
>> -=-=-=-=-=-
>>
>> Module Name: src
>> Committed By:maxv
>> Date:Wed Jun 26 20:28:59 UTC 2019
>>
>> Modified Files:
>> src/sys/kern:
In article <20190626202859.b5ccef...@cvs.netbsd.org>,
Maxime Villard wrote:
>-=-=-=-=-=-
>
>Module Name: src
>Committed By: maxv
>Date: Wed Jun 26 20:28:59 UTC 2019
>
>Modified Files:
> src/sys/kern: kern_exec.c
>
>Log Message:
>Remove useless debugging messages which achieved
"Maxime Villard" writes:
> Module Name: src
> Committed By: maxv
> Date: Wed Jun 26 20:28:59 UTC 2019
>
> Modified Files:
> src/sys/kern: kern_exec.c
>
> Log Message:
> Remove useless debugging messages which achieved nothing but hiding bugs.
considering the author of these
On Jun 26, 10:30pm, m...@m00nbsd.net (Maxime Villard) wrote:
-- Subject: Re: CVS commit: src/sys/kern
| Le 25/06/2019 à 23:32, Christos Zoulas a écrit :
| > Module Name:src
| > Committed By: christos
| > Date: Tue Jun 25 21:32:58 UTC 2019
| >
| >
Le 25/06/2019 à 23:32, Christos Zoulas a écrit :
Module Name:src
Committed By: christos
Date: Tue Jun 25 21:32:58 UTC 2019
Modified Files:
src/sys/kern: kern_exec.c
Log Message:
Fail if getcwd fails. Pointed out by maxv@
To generate a diff of this commit:
cvs rdiff -u
Le 25/06/2019 à 20:06, Christos Zoulas a écrit :
Module Name:src
Committed By: christos
Date: Tue Jun 25 18:06:29 UTC 2019
Modified Files:
src/sys/kern: kern_exec.c
Log Message:
add a comment explaining what this does.
To generate a diff of this commit:
cvs rdiff -u
On Tue, Jun 25, 2019 at 4:03 PM Nick Hudson wrote:
>
> On 24/06/2019 10:40, Ryota Ozaki wrote:
> > On Mon, Jun 24, 2019 at 6:27 PM matthew green wrote:
> >>
> >>> Only KERNEL_LOCK (and some splsoftnet) is required for the network stack
> >>> now. Remaining splnets are for network drivers.
On 24/06/2019 10:40, Ryota Ozaki wrote:
On Mon, Jun 24, 2019 at 6:27 PM matthew green wrote:
Only KERNEL_LOCK (and some splsoftnet) is required for the network stack
now. Remaining splnets are for network drivers. (softnet_lock is also required
in some cases but it's another story...)
On Mon, Jun 24, 2019 at 9:39 AM Ryota Ozaki wrote:
>
> On Mon, Jun 24, 2019 at 6:27 PM matthew green wrote:
> >
> > > Only KERNEL_LOCK (and some splsoftnet) is required for the network stack
> > > now. Remaining splnets are for network drivers. (softnet_lock is also
> > > required
> > > in
On Mon, Jun 24, 2019 at 6:27 PM matthew green wrote:
>
> > Only KERNEL_LOCK (and some splsoftnet) is required for the network stack
> > now. Remaining splnets are for network drivers. (softnet_lock is also
> > required
> > in some cases but it's another story...)
>
> great! i studied the code
> Only KERNEL_LOCK (and some splsoftnet) is required for the network stack
> now. Remaining splnets are for network drivers. (softnet_lock is also
> required
> in some cases but it's another story...)
great! i studied the code and i couldn't find any issues
in any of the relevant paths, so
On Mon, Jun 24, 2019 at 5:26 PM Manuel Bouyer wrote:
>
> On Mon, Jun 24, 2019 at 08:39:08AM +0100, Nick Hudson wrote:
> >
> >
> > On 24/06/2019 04:30, matthew green wrote:
> > > > > splnet is obsolete in modern USB network drivers.
> > > > > all the code runs at softipl.
> > > > >
> > > > >
On Mon, Jun 24, 2019 at 08:39:08AM +0100, Nick Hudson wrote:
>
>
> On 24/06/2019 04:30, matthew green wrote:
> > > > splnet is obsolete in modern USB network drivers.
> > > > all the code runs at softipl.
> > > >
> > > > removing spl was done entirely on purpose.
> > >
> > > I saw the comment
On 24/06/2019 04:30, matthew green wrote:
splnet is obsolete in modern USB network drivers.
all the code runs at softipl.
removing spl was done entirely on purpose.
I saw the comment of ether_ioctl in sys/net/if_ethersubr.c
Note, we must be called at splnet().
so I asked.
that comment
On Mon, Jun 24, 2019 at 01:30:09PM +1000, matthew green wrote:
> > > splnet is obsolete in modern USB network drivers.
> > > all the code runs at softipl.
> > >
> > > removing spl was done entirely on purpose.
> >
> > I saw the comment of ether_ioctl in sys/net/if_ethersubr.c
> > > Note, we must
> > splnet is obsolete in modern USB network drivers.
> > all the code runs at softipl.
> >
> > removing spl was done entirely on purpose.
>
> I saw the comment of ether_ioctl in sys/net/if_ethersubr.c
> > Note, we must be called at splnet().
> so I asked.
that comment is true for old style
On Sun, Jun 23, 2019 at 10:40 PM matthew green wrote:
>
> sc dying writes:
> > hi,
> >
> > On Sat, Jun 22, 2019 at 9:54 AM matthew green wrote:
> > >
> > > Module Name:src
> > > Committed By: mrg
> > > Date: Sat Jun 22 09:53:56 UTC 2019
> > >
> > > Modified Files:
> > >
sc dying writes:
> hi,
>
> On Sat, Jun 22, 2019 at 9:54 AM matthew green wrote:
> >
> > Module Name:src
> > Committed By: mrg
> > Date: Sat Jun 22 09:53:56 UTC 2019
> >
> > Modified Files:
> > src/sys/dev/usb: if_axen.c
> >
> > Log Message:
> > mark this driver MPSAFE for
hi,
On Sun, Jun 23, 2019 at 2:14 AM matthew green wrote:
>
> Module Name:src
> Committed By: mrg
> Date: Sun Jun 23 02:14:15 UTC 2019
>
> Modified Files:
> src/sys/dev/usb: if_cdce.c if_ure.c if_urevar.h
>
> Log Message:
> make cdce(4) and ure(4) usb and mpsafe:
>
> -
hi,
On Sat, Jun 22, 2019 at 9:54 AM matthew green wrote:
>
> Module Name:src
> Committed By: mrg
> Date: Sat Jun 22 09:53:56 UTC 2019
>
> Modified Files:
> src/sys/dev/usb: if_axen.c
>
> Log Message:
> mark this driver MPSAFE for usb tasks and pipes, if(4), and callouts.
On Sun, Jun 23, 2019 at 01:13:20PM +, m...@netbsd.org wrote:
> On Mon, May 06, 2019 at 08:05:03AM +, Kamil Rytarowski wrote:
> > KSI_INIT_TRAP();
> > ksi.ksi_lid = l->l_lid;
> > - ksi.ksi_info._signo = signo;
> > - ksi.ksi_info._code = trapno;
> > + ksi.ksi_signo = signo;
> >
On Mon, May 06, 2019 at 08:05:03AM +, Kamil Rytarowski wrote:
> KSI_INIT_TRAP();
> ksi.ksi_lid = l->l_lid;
> - ksi.ksi_info._signo = signo;
> - ksi.ksi_info._code = trapno;
> + ksi.ksi_signo = signo;
> + ksi.ksi_code = trapno;
I suspect no longer setting
On 19.06.2019 06:41, m...@netbsd.org wrote:
> On Tue, Jun 18, 2019 at 09:18:13PM +, Kamil Rytarowski wrote:
>> Module Name: src
>> Committed By:kamil
>> Date:Tue Jun 18 21:18:13 UTC 2019
>>
>> Modified Files:
>> src/sys/arch/aarch64/include: ptrace.h
>>
On Tue, Jun 18, 2019 at 09:18:13PM +, Kamil Rytarowski wrote:
> Module Name: src
> Committed By: kamil
> Date: Tue Jun 18 21:18:13 UTC 2019
>
> Modified Files:
> src/sys/arch/aarch64/include: ptrace.h
> src/sys/arch/alpha/include: ptrace.h
>
Hi,
chris...@zoulas.com (Christos Zoulas) writes:
> On Jun 18, 9:37pm, r...@tetera.org (Ryo ONODERA) wrote:
> -- Subject: Re: CVS commit: src/sys/conf
>
> | chris...@astron.com (Christos Zoulas) writes:
> |
> | > Yes, the question becomes should be part of the default G
On Jun 18, 9:37pm, r...@tetera.org (Ryo ONODERA) wrote:
-- Subject: Re: CVS commit: src/sys/conf
| chris...@astron.com (Christos Zoulas) writes:
|
| > Yes, the question becomes should be part of the default GENERIC build?
| > I think not (like before).
|
| I feel that chfs should be di
chris...@astron.com (Christos Zoulas) writes:
> Yes, the question becomes should be part of the default GENERIC build?
> I think not (like before).
I feel that chfs should be disabled by default.
And hopefully it should be documented that flash(4) is required
in filesystems.config or similar
In article <87muigi0qk@brownie.elements.tetera.org>,
Ryo ONODERA wrote:
>Hi,
>
>"Christos Zoulas" writes:
>
>> Module Name: src
>> Committed By:christos
>> Date:Mon Jun 17 17:06:39 UTC 2019
>>
>> Modified Files:
>> src/sys/conf: filesystems.config
>>
>> Log
Hi,
"Christos Zoulas" writes:
> Module Name: src
> Committed By: christos
> Date: Mon Jun 17 17:06:39 UTC 2019
>
> Modified Files:
> src/sys/conf: filesystems.config
>
> Log Message:
> comment out CHFS to fix build issues
I have the following lines in my local kernel config file
On Sun, 16 Jun 2019, Christos Zoulas wrote:
No, there is still an issue. The change adds those files in the kernel when
there are no filesystems present. Otherwise I just built a MODULAR kernel
with FFS disabled and I get:
Don't you get the same? Or don't you have quotas or extended attributes
I did not rearrange where things live (or I don't understand what you mean by
that).
I just uncommented the no filesystem FFS from MODULAR, and tried to compile.
Does it compile for you without my changes?
christos
> On Jun 16, 2019, at 8:10 PM, Paul Goyette wrote:
>
>
No, there is still an issue. The change adds those files in the kernel when
there are no filesystems present. Otherwise I just built a MODULAR kernel
with FFS disabled and I get:
Don't you get the same? Or don't you have quotas or extended attributes on
in your kernel?
christos
ld:
On Sun, 16 Jun 2019, Paul Goyette wrote:
If I'm understanding your changes correctly, a kernel will have a copy
of ufs_quota.c built-in, whether or not the ffs code is built-in. So
if you have a kernel with no ffs, that kernel will still have the quota
code, and loading the ffs module will
On Sun, 16 Jun 2019, Christos Zoulas wrote:
I did not rearrange where things live (or I don't understand what you
mean by that). I just uncommented the no filesystem FFS from MODULAR,
and tried to compile.
The various sys/modules/*/Makefiles also specifically include the same
files in the
On Sun, 16 Jun 2019, Paul Goyette wrote:
Hmmm, I wonder why this is needed?
I have NO built-in filesystems in my custom kernel, and it has not had any
linkage problems in many years.
# modstat | grep vfs
ffs vfs boot -0 - wapbl
kernfs vfs
Hmmm, I wonder why this is needed?
I have NO built-in filesystems in my custom kernel, and it has not had
any linkage problems in many years.
# modstat | grep vfs
ffs vfs boot -0 - wapbl
kernfs vfs filesys a0 - -
null
> > also, what's IST_MPSAFE? sounds like some platform specific
> > thing.
>
> Sure. Each platform should have it's own. Unless someone wants to make an
> MI intr_establish.
then it's not useful for MI driver.
you quote spl(9):
>At the time of writing, the global kernel_lock is
On 31/05/2019 07:27, matthew green wrote:
> Nick Hudson writes:
>> On 30/05/2019 21:46, matthew green wrote:
Committed By: tnn
Date: Thu May 30 07:37:17 UTC 2019
Modified Files:
src/sys/dev/ic: ssdfb.c
Log Message:
- include uvm.h
Nick Hudson writes:
> On 30/05/2019 21:46, matthew green wrote:
> >> Committed By: tnn
> >> Date: Thu May 30 07:37:17 UTC 2019
> >>
> >> Modified Files:
> >>src/sys/dev/ic: ssdfb.c
> >>
> >> Log Message:
> >> - include uvm.h before uvm_device.h
> >> - don't need IPL_SCHED
On 30/05/2019 21:46, matthew green wrote:
Committed By: tnn
Date: Thu May 30 07:37:17 UTC 2019
Modified Files:
src/sys/dev/ic: ssdfb.c
Log Message:
- include uvm.h before uvm_device.h
- don't need IPL_SCHED here
the IPL_SCHED change seems backwards to me.
IPL_VM is the
> Committed By: tnn
> Date: Thu May 30 07:37:17 UTC 2019
>
> Modified Files:
> src/sys/dev/ic: ssdfb.c
>
> Log Message:
> - include uvm.h before uvm_device.h
> - don't need IPL_SCHED here
the IPL_SCHED change seems backwards to me.
IPL_VM is the "this driver is not updated to
# Sorry for too delayed response..
At Mon, 6 May 2019 19:33:43 +0100,
Sevan Janiyan wrote:
> > What is the difference in m68k family?
> > Enabled: amiga, cesfic, hp300, mac68k, news68k, next68k
> > Disabled: atari, luna68k, mvme68k, sun3, x68k
>
> You can have systems with more than 32MB RAM
Oh, should've tested that. Survived kernels and distribution:
diff --git a/sys/arch/sparc64/sparc64/db_trace.c
b/sys/arch/sparc64/sparc64/db_trace.c
index f5e35e79dd51..d94e5eb2d2ef 100644
--- a/sys/arch/sparc64/sparc64/db_trace.c
+++ b/sys/arch/sparc64/sparc64/db_trace.c
@@ -36,6 +36,7 @@
This breaks the build of usr.sbin/crash:
/work/build/src/usr.sbin/crash/../../sys/arch/sparc64/sparc64/db_trace.c: In
function 'db_stack_trace_print':
/work/build/src/usr.sbin/crash/../../sys/arch/sparc64/sparc64/db_trace.c:166:37:
error: 'VM_MAX_KERNEL_ADDRESS' undeclared (first use in this
Date:Mon, 20 May 2019 16:35:45 -0400
From:"Christos Zoulas"
Message-ID: <20190520203545.b41f6f...@cvs.netbsd.org>
| Add a simple vasprintf() implementation that uses 2 passes, one to compute
| the length and a second to place the data. Requested by rmind@
On 2019/05/16 13:20, Jason Thorpe wrote:
>
>
>> On May 15, 2019, at 9:19 PM, Maxime Villard wrote:
>>
>> Le 16/05/2019 à 04:36, SAITOH Masanobu a écrit :
>>> Module Name:src
>>> Committed By: msaitoh
>>> Date: Thu May 16 02:36:30 UTC 2019
>>> Modified Files:
>>>
On 2019/05/16 13:19, Maxime Villard wrote:
> Le 16/05/2019 à 04:36, SAITOH Masanobu a écrit :
>> Module Name: src
>> Committed By: msaitoh
>> Date: Thu May 16 02:36:30 UTC 2019
>>
>> Modified Files:
>> src/sys/arch/x86/x86: procfs_machdep.c
>>
>> Log Message:
>> Use
> On May 15, 2019, at 9:19 PM, Maxime Villard wrote:
>
> Le 16/05/2019 à 04:36, SAITOH Masanobu a écrit :
>> Module Name: src
>> Committed By:msaitoh
>> Date:Thu May 16 02:36:30 UTC 2019
>> Modified Files:
>> src/sys/arch/x86/x86: procfs_machdep.c
>> Log Message:
Le 16/05/2019 à 04:36, SAITOH Masanobu a écrit :
Module Name:src
Committed By: msaitoh
Date: Thu May 16 02:36:30 UTC 2019
Modified Files:
src/sys/arch/x86/x86: procfs_machdep.c
Log Message:
Use ci_feat_val[7] instead of directly getting cpuid 7 edx.
To generate a
On Tue, May 14, 2019 at 10:54 PM Greg Troxel wrote:
>
> Ryota Ozaki writes:
>
> > On Tue, May 14, 2019 at 2:31 AM Jason Thorpe wrote:
> >>
> >>
> >>
> >> > On May 13, 2019, at 7:17 AM, Greg Troxel wrote:
> >> >
> >> > 2) Your option 2 seems to involve two things at once:
> >> >
> >> > -
Ryota Ozaki writes:
>> And, if someone is inclined, having better checks with meaurable
>> slowdown under DEBUG sounds ok too, but my revised understanding is
>> unclear on whether that's helpful. (But I am only trying to keep
>> performance under DIAGNOSTIC high; I am unconcerned about DEBUG
Ryota Ozaki writes:
> On Tue, May 14, 2019 at 2:31 AM Jason Thorpe wrote:
>>
>>
>>
>> > On May 13, 2019, at 7:17 AM, Greg Troxel wrote:
>> >
>> > 2) Your option 2 seems to involve two things at once:
>> >
>> > - migration to lwp_specificadata
>> > - using DEBUG instead of DIAGNOSTIC to
On Tue, May 14, 2019 at 2:31 AM Jason Thorpe wrote:
>
>
>
> > On May 13, 2019, at 7:17 AM, Greg Troxel wrote:
> >
> > 2) Your option 2 seems to involve two things at once:
> >
> > - migration to lwp_specificadata
> > - using DEBUG instead of DIAGNOSTIC to control the leak check feature
> >
> >
On Tue, May 07, 2019 at 09:22:49AM +0800, Paul Goyette wrote:
> Currently we have the global sysctl variable, but I wonder if it should be
> made local to a particular emulation and/or to an individual process?
It's a global flag because it has security impliciations. Making it
per-emulation or
On Mon, May 13, 2019 at 04:55:17PM +, Manuel Bouyer wrote:
> Module Name: src
> Committed By: bouyer
> Date: Mon May 13 16:55:17 UTC 2019
>
> Modified Files:
> src/sys/arch/arm/sunxi: sunxi_sata.c
>
> Log Message:
> Use new magic values from linux for DMACR. While I couldn't
> On May 13, 2019, at 7:17 AM, Greg Troxel wrote:
>
> 2) Your option 2 seems to involve two things at once:
>
> - migration to lwp_specificadata
> - using DEBUG instead of DIAGNOSTIC to control the leak check feature
>
> I do not understand why changing the nature of the implementation is
Ryota Ozaki writes:
> On Sat, May 11, 2019 at 10:49 AM Greg Troxel wrote:
>> >> I'm sorry for delaying this task. Finally I have benchmarked a revised
>> >> patch
>> >> (our benchmarking setups have been out of service for a couple of
>> >> weeks...).
>> >>
>> >> Performance degradation of
On Sat, May 11, 2019 at 10:49 AM Greg Troxel wrote:
>
> Kamil Rytarowski writes:
>
> > On 08.05.2019 11:34, Ryota Ozaki wrote:
> >> On Sat, Apr 20, 2019 at 6:45 PM Ryota Ozaki wrote:
> >>>
> >>> On Fri, Apr 19, 2019 at 6:49 PM Kamil Rytarowski wrote:
>
> On 19.04.2019 11:41, J.
Kamil Rytarowski writes:
> On 08.05.2019 11:34, Ryota Ozaki wrote:
>> On Sat, Apr 20, 2019 at 6:45 PM Ryota Ozaki wrote:
>>>
>>> On Fri, Apr 19, 2019 at 6:49 PM Kamil Rytarowski wrote:
On 19.04.2019 11:41, J. Hannken-Illjes wrote:
>> On 19. Apr 2019, at 03:52, Ryota Ozaki wrote:
1101 - 1200 of 5581 matches
Mail list logo
