On Tue, May 19, 2020 at 11:09:07PM +, Andrew Doran wrote:
> vnode locks are not held during getpages/putpages.
^ for fault handling, anyway. for read/write they are held by the caller to
ubc_uiomove().
Andrew
On Sun, May 17, 2020 at 11:49:52PM +, m...@netbsd.org wrote:
> On Sun, May 17, 2020 at 09:47:50PM +, m...@netbsd.org wrote:
> > On Sun, May 17, 2020 at 07:39:15PM +, Andrew Doran wrote:
> > > Module Name: src
> > > Committed By: ad
> > > Date: Sun May 17 19:39:15
On Sun, May 17, 2020 at 09:47:50PM +, m...@netbsd.org wrote:
> On Sun, May 17, 2020 at 07:39:15PM +, Andrew Doran wrote:
> > Module Name:src
> > Committed By: ad
> > Date: Sun May 17 19:39:15 UTC 2020
> >
> > Modified Files:
> > src/sys/fs/tmpfs: tmpfs.h
On Sun, May 17, 2020 at 07:39:15PM +, Andrew Doran wrote:
> Module Name: src
> Committed By: ad
> Date: Sun May 17 19:39:15 UTC 2020
>
> Modified Files:
> src/sys/fs/tmpfs: tmpfs.h tmpfs_subr.c tmpfs_vnops.c
>
> Log Message:
> PR kern/55268: tmpfs is slow
>
>
On Wed, Jan 11, 2017 at 09:12:33PM +, David Holland wrote:
> On Wed, Jan 11, 2017 at 12:12:33PM +, Joerg Sonnenberger wrote:
> > Modified Files:
> >src/sys/fs/tmpfs: tmpfs_vnops.c
> >
> > Log Message:
> > Remove RO check in tmpfs_putpages for now, the syncer doesn't like the
> >
On Wed, Jan 11, 2017 at 12:12:33PM +, Joerg Sonnenberger wrote:
> Modified Files:
> src/sys/fs/tmpfs: tmpfs_vnops.c
>
> Log Message:
> Remove RO check in tmpfs_putpages for now, the syncer doesn't like the
> error code.
Either removing it is wrong or it should be changed to
J. Hannken-Illjes hann...@eis.cs.tu-bs.de wrote:
On Jan 8, 2014, at 5:11 PM, pedro martelletto pe...@netbsd.org wrote:
Module Name:src
Committed By: pedro
Date: Wed Jan 8 16:11:04 UTC 2014
Modified Files:
src/sys/fs/tmpfs: tmpfs_subr.c
Log
On Jan 8, 2014, at 5:11 PM, pedro martelletto pe...@netbsd.org wrote:
Module Name: src
Committed By: pedro
Date: Wed Jan 8 16:11:04 UTC 2014
Modified Files:
src/sys/fs/tmpfs: tmpfs_subr.c
Log Message:
Allocate direntp on the stack in tmpfs_dir_getdents(), thus saving
On Jan 3, 2014, at 10:18 PM, J. Hannken-Illjes hann...@eis.cs.tu-bs.de wrote:
On Jan 3, 2014, at 10:13 PM, Mindaugas Rasiukevicius rm...@netbsd.org wrote:
Juergen Hannken-Illjes hann...@netbsd.org wrote:
Module Name:src
Committed By: hannken
Date: Fri Jan 3
Juergen Hannken-Illjes hann...@netbsd.org wrote:
Module Name: src
Committed By: hannken
Date: Fri Jan 3 09:53:12 UTC 2014
Modified Files:
src/sys/fs/tmpfs: tmpfs_subr.c tmpfs_vnops.c
Log Message:
Fix a race where thread1 runs VOP_REMOVE() and gets preempted in
On Jan 3, 2014, at 10:13 PM, Mindaugas Rasiukevicius rm...@netbsd.org wrote:
Juergen Hannken-Illjes hann...@netbsd.org wrote:
Module Name: src
Committed By:hannken
Date:Fri Jan 3 09:53:12 UTC 2014
Modified Files:
src/sys/fs/tmpfs: tmpfs_subr.c tmpfs_vnops.c
On Nov 8, 2013, at 4:44 PM, Mindaugas Rasiukevicius rm...@netbsd.org wrote:
Module Name: src
Committed By: rmind
Date: Fri Nov 8 15:44:23 UTC 2013
Modified Files:
src/sys/fs/tmpfs: tmpfs.h tmpfs_rename.c tmpfs_subr.c tmpfs_vfsops.c
tmpfs_vnops.c
Log Message:
J. Hannken-Illjes hann...@eis.cs.tu-bs.de wrote:
Module Name:src
Committed By: rmind
Date: Fri Nov 8 15:44:23 UTC 2013
...
The tests fs/vfs/t_union/tmpfs_basic and fs/vfs/t_union/tmpfs_whiteout
start failing after this commit.
Fixed.
--
Mindaugas
Forgot to add that this also fixes a space leak in tmpfs_rename,
introduced a couple months ago, which nobody reported as far as I
know. The leak sometimes caused tmpfs_renamerace_dirs to fail with
ENOSPC. The problem was that renaming a directory over an empty
directory would fail to decrement
On Thu, Aug 18, 2011 at 09:51:50PM +, Taylor R Campbell wrote:
Forgot to add that this also fixes a space leak in tmpfs_rename,
introduced a couple months ago, which nobody reported as far as I
know. The leak sometimes caused tmpfs_renamerace_dirs to fail with
ENOSPC. The problem was
On May 14, 2011, at 1:43 PM, Martin Husemann wrote:
On Sat, May 14, 2011 at 10:34:05AM +0200, Marc Balmer wrote:
What is the current state of C99 vs. older Cs? Do all arches /
compilers we have support C99?
We have lost the playstation2 port, because we don't have a working C99
compiler
On Fri, May 13, 2011 at 06:37:53PM +0100, Mindaugas Rasiukevicius wrote:
Generally - C99 is encouraged. However, I disagree that variables
should be declared in the middle of context (for a minimum scope),
unless there is a *clear* benefit. Otherwise, it makes code harder
to read,
On Sat, May 14, 2011 at 2:37 AM, Mindaugas Rasiukevicius
rm...@netbsd.org wrote:
Matt Thomas m...@3am-software.com wrote:
On May 7, 2011, at 5:03 PM, Christos Zoulas wrote:
Module Name: src
Committed By: christos
Date: Sun May 8 00:03:35 UTC 2011
Modified
Am 10.05.11 02:34, schrieb Matt Thomas:
Module Name: src
Committed By: matt
Date: Tue May 10 00:34:26 UTC 2011
Modified Files:
src/sys/fs/tmpfs: tmpfs_vnops.c
Log Message:
yes, more C99 please (back out previous change).
After this
On 05/14/2011 10:34 AM, Marc Balmer wrote:
Am 10.05.11 02:34, schrieb Matt Thomas:
Module Name:src
Committed By: matt
Date: Tue May 10 00:34:26 UTC 2011
Modified Files:
src/sys/fs/tmpfs: tmpfs_vnops.c
Log Message:
yes, more C99 please (back out previous change).
After
Am 14.05.11 10:45, schrieb Anders Magnusson:
[...]
What is the current state of C99 vs. older Cs? Do all arches /
compilers we have support C99? I assume gcc, llvm/clang are safe, but
what about pcc wrt C99?
pcc should be C99 compliant. If something do not work as expected, I'll
fix it.
On Sat, 14 May 2011, Marc Balmer wrote:
What is the current state of C99 vs. older Cs? Do all arches /
compilers we have support C99? I assume gcc, llvm/clang are safe, but
what about pcc wrt C99?
I'd like a short clarification here, since this might influence my
coding... tnx.
pcc is a
Masao Uebayashi uebay...@gmail.com wrote:
The kernel explicitly allows C99 and actually C99 is encouraged.
So that should reverted :)
Generally - C99 is encouraged. However, I disagree that variables
should be declared in the middle of context (for a minimum scope),
unless there is a
On May 14, 12:00pm, rm...@netbsd.org (Mindaugas Rasiukevicius) wrote:
-- Subject: Re: CVS commit: src/sys/fs/tmpfs
| Benefit is code readability. It is easier to track the variables when
| they are defined and initialised in the beginning of context.
|
| If code is longer and/or complex
On Sat, May 14, 2011 at 12:07:20PM -0400, Christos Zoulas wrote:
If we are going to be compiling the kernel in c99 mode, then I
suggest that we do the same for userland instead of turning it on
for userland piecemeal.
+1
is there anything we expect to break?
--
David A. Holland
14.05.2011, 10:38, Masao Uebayashi uebay...@gmail.com:
I disagree. If variables are declared in the middle of context, those
variables have narrower contexts. Narrowing context is always a win
IMO.
That's true only if you don't use gotos. Otherwise, you might jump past
an initialization
On Sat, May 14, 2011 at 10:34:05AM +0200, Marc Balmer wrote:
What is the current state of C99 vs. older Cs? Do all arches /
compilers we have support C99?
We have lost the playstation2 port, because we don't have a working C99
compiler for it (so a -current kernel can not be compiled).
Martin
On Tue, 10 May 2011, Takahiro Kambe wrote:
In message 20110509170006.GA15831@marx.bitnet
on Mon, 9 May 2011 20:00:06 +0300,
Jukka Ruohonen jruoho...@iki.fi wrote:
On Mon, May 09, 2011 at 06:50:08PM +0200, Adam Hoka wrote:
So can we use for (int i = 0; ... ? :p
lint(1) support
In message alpine.neb.2.00.1105100716550.29...@galant.ukfsn.org
on Tue, 10 May 2011 07:19:51 +0100 (BST),
Iain Hibbert plu...@rya-online.net wrote:
On Tue, 10 May 2011, Takahiro Kambe wrote:
In message 20110509170006.GA15831@marx.bitnet
on Mon, 9 May 2011 20:00:06 +0300,
On May 8, 9:21pm, m...@3am-software.com (Matt Thomas) wrote:
-- Subject: Re: CVS commit: src/sys/fs/tmpfs
| The kernel explicitly allows C99 and actually C99 is encouraged.
| So that should reverted :)
Test it. Build a DEBUG kernel and when it works, you can or I will revert it.
In this case
On Mon, May 09, 2011 at 06:50:08PM +0200, Adam Hoka wrote:
So can we use for (int i = 0; ... ? :p
Hopefully not...
- Jukka.
On May 9, 2011, at 5:25 AM, Christos Zoulas wrote:
On May 8, 9:21pm, m...@3am-software.com (Matt Thomas) wrote:
-- Subject: Re: CVS commit: src/sys/fs/tmpfs
| The kernel explicitly allows C99 and actually C99 is encouraged.
| So that should reverted :)
Test it. Build a DEBUG kernel
On May 9, 10:23am, m...@3am-software.com (Matt Thomas) wrote:
-- Subject: Re: CVS commit: src/sys/fs/tmpfs
|
| On May 9, 2011, at 5:25 AM, Christos Zoulas wrote:
|
| On May 8, 9:21pm, m...@3am-software.com (Matt Thomas) wrote:
| -- Subject: Re: CVS commit: src/sys/fs/tmpfs
| =20
In message 20110509170006.GA15831@marx.bitnet
on Mon, 9 May 2011 20:00:06 +0300,
Jukka Ruohonen jruoho...@iki.fi wrote:
On Mon, May 09, 2011 at 06:50:08PM +0200, Adam Hoka wrote:
So can we use for (int i = 0; ... ? :p
lint(1) support them?
Hopefully not...
Me, too.
--
On May 9, 2011, at 4:35 PM, Christos Zoulas wrote:
| Been doing DEBUG builds with tmpfs for a long time with no problems.
|
| In this case it thinks that i is used out of the loop.
|
| Where? After the for loop, it returns.
Well, just add back the commented out #CPPFLAGS+=-DDEBUG in
On May 9, 2011, at 10:00 AM, Jukka Ruohonen wrote:
On Mon, May 09, 2011 at 06:50:08PM +0200, Adam Hoka wrote:
So can we use for (int i = 0; ... ? :p
Hopefully not...
For the kernel, for (int ... is allowed.
On May 7, 2011, at 5:03 PM, Christos Zoulas wrote:
Module Name: src
Committed By: christos
Date: Sun May 8 00:03:35 UTC 2011
Modified Files:
src/sys/fs/tmpfs: tmpfs_vnops.c
Log Message:
no c99 please.
The kernel explicitly allows C99 and actually C99 is encouraged.
So
Simon Burge sim...@netbsd.org wrote:
Simplify tmpfs_itimes() and use vfs_timestamp(). [ ... ]
Was changing from getnanotime() to effectively nanotime() (via
vfs_timestamp()) deliberate? The original intention of using
getnanotime() for filesystem timestamps was that having a perfect
hi,
Mindaugas Rasiukevicius wrote:
Module Name: src
Committed By:rmind
Date:Wed Nov 11 09:59:42 UTC 2009
Modified Files:
src/sys/fs/tmpfs: tmpfs_subr.c
Log Message:
Simplify tmpfs_itimes() and use vfs_timestamp(). [ ... ]
Was changing from
On Tue Apr 28 2009 at 00:29:05 +, YAMAMOTO Takashi wrote:
Hmm, does this work correctly if you find the component via the
cache_lookup() path?
Ok, I dug into this a little. Short answer: no, but ...
It seems that cache_lookup() always returns false if MAKEENTRY is not set.
hi,
On Fri Apr 24 2009 at 18:00:45 +0300, Antti Kantee wrote:
On Sat Apr 11 2009 at 20:42:59 +, Andrew Doran wrote:
On Sat, Apr 11, 2009 at 12:21:57AM +, Perry E. Metzger wrote:
Modified Files:
src/sys/fs/tmpfs: tmpfs_vnops.c
Log Message:
SAVENAME was not set for
On Sat Apr 11 2009 at 20:42:59 +, Andrew Doran wrote:
On Sat, Apr 11, 2009 at 12:21:57AM +, Perry E. Metzger wrote:
Modified Files:
src/sys/fs/tmpfs: tmpfs_vnops.c
Log Message:
SAVENAME was not set for rename and delete as required
Patch from christos, fixes pr 41183
On Fri Apr 10 2009 at 22:36:38 +, Andrew Doran wrote:
On Sat, Apr 11, 2009 at 01:32:09AM +0300, Antti Kantee wrote:
On Fri Apr 10 2009 at 21:34:10 +, Andrew Doran wrote:
On Fri, Apr 10, 2009 at 06:57:45PM +0200, Frank Kardel wrote:
It may be related: I am now seeing a tmpfs
43 matches
Mail list logo
