On Sun, Dec 08, 2013 at 11:44:28PM +0100, Joerg Sonnenberger wrote:
I have done it by having the original, non-_r functions provide a
thunk for the comparison function, as this is least invasive. If we
think this is too expensive, an alternative is generating a union of
function
On Sun, Dec 08, 2013 at 11:26:47PM +, David Laight wrote:
I have done it by having the original, non-_r functions provide a
thunk for the comparison function, as this is least invasive. If we
think this is too expensive, an alternative is generating a union of
function pointers
On Sun, Dec 08, 2013 at 11:51:15PM -0500, Mouse wrote:
If you can find me a description of what NetBSD assumes beyond what C
promises, I can have a stab at answering that question. (I know a few
of the things, such as there is an exactly-8-bit type, but I feel
fairly sure I don't know
On Mon, Dec 09, 2013 at 12:59:49AM -0500, Mouse wrote:
[...]. In this environment I don't think it's a good idea to make
any assumptions at all about things the C standard doesn't guarantee.
Then there are a lot of things that need fixing; the one I'm most aware
of is the assumption
On Sun, Dec 08, 2013 at 10:50:15PM +, David Holland wrote:
I have done it by having the original, non-_r functions provide a
thunk for the comparison function, as this is least invasive. If we
think this is too expensive, an alternative is generating a union of
function
On Mon, Dec 09, 2013 at 01:49:29AM -0500, Mouse wrote:
Then there are a lot of things that need fixing; the one I'm most
aware of is the assumption that all-bits-0 is a nil pointer.
Yes. I think the official stance on that is to worry about it when a
real platform appears where it
On Mon, Dec 09, 2013 at 06:10:36AM +, Alan Barrett wrote:
My irritation with not being able to pass a data pointer through
qsort() boiled over just now. Apparently Linux and/or GNU has a
qsort_r() that supports this; so, following is a patch that gives
us a compatible qsort_r() plus
corrections from Mouse:
On Mon, Dec 09, 2013 at 07:02:39AM +, David Holland wrote:
(2) union of function pointers
r = is_r ? cmpu.cmp(a, b) : cmpu.cmp_r(a, b, data);
this test is backwards.
void
sort(void *p, size_t n, size_t sz, int (*cmp)(const void *, const void
On Mon, Dec 30, 2013 at 11:35:48AM +0100, J. Hannken-Illjes wrote:
The layered file systems hashlists currently have to work on locked
vnodes as the vnode operations returning vnodes return them locked.
This leads to some very dirty hacks -- see layer_node_find() from
On Mon, Dec 30, 2013 at 05:26:14PM +0100, J. Hannken-Illjes wrote:
This seems to largely add code to file systems to mess with locking
further, rather than reducing that code.
What do you mean with mess here?
Can you explain how this
change helps to clean up those dirty hacks?
On Tue, Dec 31, 2013 at 11:34:27AM +0100, J. Hannken-Illjes wrote:
The layered file systems hashlists currently have to work on locked
vnodes as the vnode operations returning vnodes return them locked.
This leads to some very dirty hacks -- see layer_node_find() from
On Tue, Jan 07, 2014 at 11:32:28AM +0100, J. Hannken-Illjes wrote:
This seems to largely add code to file systems to mess with locking
further, rather than reducing that code.
What do you mean with mess here?
Can you explain how this
change helps to clean up those dirty
On Tue, Jan 07, 2014 at 11:30:40AM +0100, J. Hannken-Illjes wrote:
(also, while this is minor I think I'd rather have vop_mkdir_args_v2
and/or vop_mkdir_desc_v2 rather than vop_mkdir2_args and
vop_mkdir2_desc. The version doesn't need to be part of the operation
name.)
Looks very
On Mon, Jan 13, 2014 at 07:39:48AM +, David Holland wrote:
In the case of VOP_SYMLINK it definitely matters, as the new symlink
isn't filled until after VOP_SYMLINK returns. Since the locking
protocol for the containing directory is to unlock it *before*
returning, it then becomes
On Mon, Jan 13, 2014 at 04:06:02PM +0100, J. Hannken-Illjes wrote:
[various nfs stuff]
Yeah, I'm not sure what to make of that either.
The reference implementation from Solaris is not atomic:
VOP_MKDIR(dvp, vp)
VOP_GETATTR(vp)
makefh(vp)
VN_RELE(vp)
VN_RELE(dvp)
They
On Wed, Jan 15, 2014 at 05:31:56PM +, Taylor R Campbell wrote:
As is, existing code calling, e.g., VOP_MKDIR will still compile. Is
there a reason the versioning doesn't rename it to VOP_MKDIR_V2?
For that matter, why new machinery for this versioning stuff at all?
Why not
On Wed, Jan 15, 2014 at 04:31:07PM +0100, J. Hannken-Illjes wrote:
I put a diff to http://www.netbsd.org/~hannken/vnode-pass2a-3.diff that
changes the vnode creation operations to keep the dvp locked.
Any objections or OK to commit?
I don't understand where all of the zfs changes arise
On Tue, Jan 21, 2014 at 05:33:41PM +, Emmanuel Dreyfus wrote:
Things would be much easier if the kernel searched /emul/netbsd64
before / for native binaries. Of course such a behavior cannot be made
default because of the performance penalty. But a compile time option
would be nice
On Tue, Jan 28, 2014 at 09:02:43PM +0100, Jean-Yves Migeon wrote:
Replacement ain't that easy, proplib(3) is used throughout the tree
in multiple places, and they are parts where a full-scale
replacement is not trivial (quotas for one).
Quotas don't use proplib. All the quota proplib stuff
On Wed, Jan 29, 2014 at 03:37:13PM +, Emmanuel Dreyfus wrote:
+panic(unexpected cmd = %d, SCARG(ua, cmd));
panic on garbage from userland really isn't the ticket.
--
David A. Holland
dholl...@netbsd.org
On Wed, Jan 29, 2014 at 05:45:51PM +, David Holland wrote:
On Wed, Jan 29, 2014 at 03:37:13PM +, Emmanuel Dreyfus wrote:
+ panic(unexpected cmd = %d, SCARG(ua, cmd));
panic on garbage from userland really isn't the ticket.
ok, so that is actually checked earlier
On Wed, Jan 29, 2014 at 01:47:36PM +0100, Edgar Fu? wrote:
I've been running my patch to correctly set the quota2 grace time in
production for four months now. Any chance to get it integrated?
Shall I file a PR?
That should have been committed, I think it flew under my radar and/or
I
On Wed, Jan 29, 2014 at 06:26:14PM +, David Laight wrote:
There is a 64bit integer type that has an alignment requirement of 8.
If that is used instead of a normal 64bit type then the structure
alignement under amd64 matches that of i386.
Also, if nothing else, the structure should be
On Fri, Feb 07, 2014 at 08:39:39AM -0800, Paul Goyette wrote:
I'm sure we have some experts who could figure this out a lot more
quickly than me fumbling through the sources :)
At my $DAYJOB we have seen instances where newfs(8) can generate a
filesystem with fragments per
On Wed, Jan 29, 2014 at 03:05:41AM +, Mindaugas Rasiukevicius wrote:
In this case, the proplib implementation has such major deficiencies that
replacing it itself is a virtue. Fixing is not the case here, as it would
basically mean rewriting.
Since this thread has died down again, here
On Sun, Feb 16, 2014 at 09:41:08PM +, David Laight wrote:
I'm adding code to i386 and amd64 to save the ymm registers on process
switch - allowing userspace to use the AVX instructions.
[ensuing crap about the u area]
Why put it in the u area at all? It's a legacy concept of little
On Mon, Feb 17, 2014 at 09:25:49PM +, David Laight wrote:
I'm adding code to i386 and amd64 to save the ymm registers on process
switch - allowing userspace to use the AVX instructions.
[ensuing crap about the u area]
Why put it in the u area at all? It's a legacy concept
On Wed, Feb 26, 2014 at 03:43:17PM +0100, Nicolas Joly wrote:
According to the OpenGroup online doccuments for truncate[1] and
ftruncate[2], there are a few cases where both syscalls should fail
when given some length values :
- EINVAL for negative length.
- EFBIG (or EINVAL) for
On Thu, Feb 06, 2014 at 04:42:07PM +, Taylor R Campbell wrote:
One more question: Are you planning to change relookup to return the
result unlocked, too? That will enable us to get rid of some ick in
genfs_rename users.
I have no plans to do it -- I'm not even sure
On Fri, Feb 28, 2014 at 03:41:33PM +, Taylor R Campbell wrote:
Also, I propose we nix the terms `recycle' and `reclaim' (except for
VOP_RECLAIM, until we rename it to VOP_DESTROY). When we're done with
a vnode, we destroy it and free its memory. When we want to grab it
from the inode
ok, I have preliminary patches that kill off DIOCDISCARD and
DIOCGDISCARDPARAMS in favor of a fdiscard system call (meant to work
on both files and devices) and add that and also a fallocate system
call.
http://www.netbsd.org/~dholland/tmp/discard/
(includes both the 17-part split patch and a
http://www.dragonflybsd.org/presentations/nanosleep/
Can someone who's familiar with the timecounter code (that is, not me)
look at this and see if we can steal their fixes?
--
David A. Holland
dholl...@netbsd.org
On Sun, Apr 06, 2014 at 12:14:24PM +0200, J. Hannken-Illjes wrote:
Currently all file systems have to implement their own cache of
vnode / fs node pairs. Most file systems use a copy and pasted
version of ufs_ihash.
So add a global vnode cache with lookup and remove:
Heh, would you
On Fri, Apr 18, 2014 at 10:13:13AM -0400, Greg Troxel wrote:
COMPAT_10 should be added in netbsd32, or removed from the native
syscall. But I'm not sure which fix should be applied.
Probably added in compat32. But I don't know how common programs are
that rely on this bug.
I
On Tue, Apr 15, 2014 at 04:11:58PM +, Taylor R Campbell wrote:
New diff at http://www.netbsd.org/~hannken/vnode-pass6-3.diff
Plan to commit early wednesday ...
I still don't think this approach is right. It makes a long-term copy
of logic in getnewvnode (because this
ok, let me try to answer this...
On Fri, Apr 11, 2014 at 12:13:52PM +0400, Ilia Zykov wrote:
I don't understand why now LOOKUP() is implemented on the two
levels - RFS and VFS.
Dividing a pathname into components (by splitting on '/') and
processing those components one at a time is done at
On Mon, Apr 28, 2014 at 07:29:44PM +0400, Ilia Zykov wrote:
First, one of the goals here is to have one table for all vnodes.
Allow me to disagree, what is advantage has only one table?
I see only disadvantage.
The reason (the only reason, really) is to bound the total size of the
On Mon, Apr 28, 2014 at 10:56:44AM +0200, J. Hannken-Illjes wrote:
Wading into this after the fact, I see the following points:
- Duplicating the getnewvnode logic is definitely bad; we have enough
cruft without adding new redundant but not quite equivalent code
paths.
- It
On Thu, May 01, 2014 at 06:49:41PM +0200, J. Hannken-Illjes wrote:
ok, in that case I think the only issue with the patch I looked at
Sunday (was it that long ago already?) is that it does duplicate the
getnewvnode logic -- if you've since fixed that I don't think I have
further
On Wed, May 14, 2014 at 01:46:19PM +, Martin Husemann wrote:
Modified Files:
src/sys/ufs/ufs: inode.h
Log Message:
Make filehandles on UFS based filesystems use proper 64bit inodes.
32bit restriction noticed by Taylor R Campbell.
I suspect this isn't going to work:
On Fri, May 16, 2014 at 12:12:00AM +0200, Joerg Sonnenberger wrote:
Modified Files:
src/sys/ufs/ufs: inode.h
Log Message:
Make filehandles on UFS based filesystems use proper 64bit inodes.
32bit restriction noticed by Taylor R Campbell.
I suspect this
On Fri, May 16, 2014 at 06:48:06PM +, Martin Husemann wrote:
The problem is that the tokens are memcmp'd, so if they include struct
padding this may not work.
All filesystems I've seen init the struct with a full memset to 0, so
all padding fields should be initialized as well.
On Sat, Apr 26, 2014 at 07:22:50PM +, David Holland wrote:
- It seems to me that in the long run, all of this baloney should be
hidden away inside the vfs layer; filesystems that use the vnode cache
should only need to call vcache_get, and the only thing that should
ever see
On Fri, May 23, 2014 at 10:56:31AM +0200, J. Hannken-Illjes wrote:
Note that the ffs code did not take the
interlock before (so before the iterator changes it was unsafe). The
machine performance is now back where it was. Without the patch
the performance regression was so bad, that
On Wed, May 14, 2014 at 08:00:56AM +1000, matthew green wrote:
thanks for looking at this. we've gotten better since early
days with these sorts of issues, but there are still a lot of
headers that are installed for no good reason but no one has
had the chance/motivation to clean them up
On Tue, May 13, 2014 at 10:36:08PM +0200, Thomas Schmitt wrote:
There are some that may be useful for userland applications
to grovel through the physical format,
isofs/cd9660/iso.h could be seen as such a thing. udf exposes
the equivalent, ecma167-udf.h.
But any interested
On Mon, May 26, 2014 at 10:11:16PM +0200, Thomas Schmitt wrote:
netbsd# dd bs=2048 count=131072 if=/dev/wd1f of=/dev/null
The short answer is: use rwd1f, not wd1f. The latter goes through the
buffer cache, but unlike when you mount it uses the old (non-unified)
buffer cache for everything...
On Mon, May 26, 2014 at 12:43:32PM +0200, Manuel Bouyer wrote:
if ((error = VFS_VGET(mp, ufhp-ufid_ino, nvp)) != 0) {
*vpp = NULLVP;
return (error);
}
ip = VTOI(nvp);
KASSERT(ip !=
On Tue, May 27, 2014 at 01:56:45AM -0400, Yizheng Jiao wrote:
do you still need any help for you BSD projects? I am a phd students. I
want to some programming project to enhance my understanding of operating
system.
A number of projects are posted here:
http://wiki.netbsd.org/projects/
On Wed, May 28, 2014 at 06:22:16PM +1000, matthew green wrote:
On Wed, May 14, 2014 at 08:00:56AM +1000, matthew green wrote:
thanks for looking at this. we've gotten better since early
days with these sorts of issues, but there are still a lot of
headers that are installed for
On Fri, May 30, 2014 at 12:01:23AM +1000, Darren Reed wrote:
[code cleanup]
All of your arguments boil down to can't trust someone else.
Why do you need to be so insulting of other developers in your arguments?
Do you think you're the only person capable of making good design
On Fri, May 30, 2014 at 09:56:15PM +1000, Darren Reed wrote:
I am surprised... no, more like shocked really... that someone as
experienced as you are could think this way.
Yes, experienced. That means I've seen all manner of code written.
And I've never before seen anyone justify a
On Wed, Jun 25, 2014 at 09:46:16AM +, Taylor R Campbell wrote:
Also, I wonder whether any file systems will ever change the length of
the key for a vnode. Probably not.
As I recall from when I was looking at this a couple weeks ago (feels
like a minor eternity ago, but it can't be much
On Tue, Jul 01, 2014 at 07:38:33PM +0100, Justin Cormack wrote:
FreeBSD recently (
http://svnweb.freebsd.org/base?view=revisionrevision=264269 ) added
elf header signature parsing to decide how to execute binaries (based
on the Linux binfmt_misc). The main use case is for qemu emulation,
A long time ago (in pine.neb.4.64.1002090351150.23...@mail.netbsd.org)
you wrote:
I do disable fsck_lfs. It usually causes more problems than it
solves. It needs a complete overhaul. It tries to act like
fsck_ffs instead of validating segment checksums and regenerating
the ifile.
A
On Wed, Jul 16, 2014 at 03:10:01PM +0200, Maxime Villard wrote:
I thought about that. I haven't found a clear spec on this, but it is
implicitly suggested that 512 is the minimal size (from what I've seen
here and there). And the smallest BytesPerSec allowed for fat devices
is 512. But
On Tue, Jul 22, 2014 at 12:54:15PM +0100, Nick Hudson wrote:
I'd guess that KMEM_REDZONE add much less than 15%.
Even if 15% were a value we'd be willing to tolerate (which I doubt),
that's 15% total, not 15% each.
Anyway, rather than shouting, can someone check what it really does
cost?
--
Currently filesystems that don't support discard fail with EOPNOTSUPP,
devices that don't support discard fail with ENODEV, and once you get
to the hardware devices that don't feel like doing TRIM fail silently
(as TRIM is an advisory operation...).
It was pointed out that it would be well to
On Sat, Aug 02, 2014 at 02:14:57AM +, ??? wrote:
I find the project on the link below is quite interesting. Who is
working on this? Can I join in?
http://wiki.netbsd.org/projects/project/improve-caching/
I don't think anyone is right now.
--
David A. Holland
dholl...@netbsd.org
On Mon, Sep 08, 2014 at 09:32:34PM +0200, Joerg Sonnenberger wrote:
Hi all,
please review the attached patch to remove the two remaining MI uses of
random(9). Neither should be in a performance critical code path and
both may actually benefit from the better distribution. The vfs_bio.c
On Mon, Sep 08, 2014 at 03:02:42PM +, Taylor R Campbell wrote:
Why the sudden spate of changes in the kernel to change keywords, move
struct and enum definitions, insert pointless casts, c.? Was this
discussed anywhere?
Beats me, and not that I saw, respectively.
--
David A. Holland
On Mon, Sep 22, 2014 at 06:28:38AM +0200, Emmanuel Dreyfus wrote:
When a PUFFS filesystem enforces quota, a process doing a write over
quota will end frozen in DE+ state.
The problem is that we have written data in the page cache that is
supposed to go to disk. The code path is a bit
On Tue, Sep 16, 2014 at 01:37:11AM +0200, Kamil Rytarowski wrote:
My proposition is to go for a new file src/sys/sys/clock.h. Normalize naming
with /usr/include/tzfile.h, then uniformly export the file for reuse across
the kernel.
#define SECSPERMIN 60L
#define MINSPERHOUR
On Sun, Sep 14, 2014 at 03:41:28AM +0200, Emmanuel Dreyfus wrote:
Retreiving a directory content through getdents() can split in multiple
calls. State is kept using the offset argument which tells where in the
directory listing buffer we want to start reading, and it is allowed to
use
On Thu, Sep 11, 2014 at 10:17:21PM -0400, vb...@andrew.cmu.edu wrote:
I am a Masters student at Carnegie Mellon University specializing in
Systems (with special emphasis on Operating Systems and Storage Systems).
I have taken a class called Operating Systems Practicum
On Tue, Sep 16, 2014 at 09:54:43PM -0400, Greg Troxel wrote:
Are these two projects already complete or been taken care of by people?
Those look like a good entry point to the file system:
- Memory-usage policies for tmpfs
On Sun, Sep 07, 2014 at 02:49:05PM -0500, Illinois Account wrote:
I was looking up into kernfs implementations, and I wanted to ask
you about what all other things should be added (what more
information should be available to user ?).
That isn't exactly clear -- the original idea of a
On Sat, Sep 27, 2014 at 12:16:43AM +, Emmanuel Dreyfus wrote:
but even ignoring that, the patch doesn't seem to actually work:
ls -ls shows that the number of blocks allocated to the file doesn't
change.
But OTOH I df shows a growing FS. Did I just managed to leak blocks that
On Mon, Oct 20, 2014 at 03:38:11PM +0200, Maxime Villard wrote:
I think the sanity check should be:
Index: ffs_vfsops.c
===
RCS file: /cvsroot/src/sys/ufs/ffs/ffs_vfsops.c,v
retrieving revision 1.299
diff -u -r1.299
On Fri, Oct 24, 2014 at 07:42:21AM +, Emmanuel Dreyfus wrote:
Is there any opposition to enable FFS extended attributes in
GENERIC?
I have been using them for a while and it seems stable, The
relevant code is only involved if the filesystem is explicitely
mounted with -o
On Sat, Oct 25, 2014 at 12:33:44AM +0700, Robert Elz wrote:
(there's another place where the error [from VOP_GETPAGES], if any,
looks to be ignored).
That doesn't sound real healthy :(
--
David A. Holland
dholl...@netbsd.org
On Fri, Oct 24, 2014 at 09:15:28PM +0200, Emmanuel Dreyfus wrote:
fsck seems like a showstopper.
We had this situation for years with quotas before QUOTA2 and it was not
a showstopper.
Yes but there's quotacheck. Is there something similar for extattrs?
--
David A. Holland
On Sun, Nov 09, 2014 at 04:16:13PM +0900, Masao Uebayashi wrote:
+#if 0
#ifndef PIPE_SOCKETPAIR
/* Initialize pipes. */
pipe_init();
@@ -604,6 +605,15 @@ main(void)
/* Initialize ptrace. */
ptrace_init();
#endif /* PTRACE */
+#else
+typedef void
On Sat, Nov 29, 2014 at 09:43:17PM +, Mindaugas Rasiukevicius wrote:
Generally, we should add an interface to flush the page cache since
it is useful for testing/benchmarking.
concur
--
David A. Holland
dholl...@netbsd.org
How many drivers are there (hardware-level drivers, not things like
raidframe) where it really matters for more than one lwp to be able to
be running (not stopped) in the driver at once?
I'm thinking probably network cards but not much else.
(This question is supposed to provoke a discussion; I
Somebody mentioned reptyr (https://github.com/nelhage/reptyr) in chat
tonight, and so I was thinking about how one might do it properly;
this is a topic I've looked at in the past from time to time, so I
think I have a viable plan for it. Which I'm going to post, both for
feedback and in the hope
On Mon, Dec 29, 2014 at 06:30:08PM +0100, Maxime Villard wrote:
most of the FSs under sys/fs have their headers in /usr/include/fs/FS-NAME/.
Some are just in /usr/include/FS-NAME/: msdosfs - adosfs - filecorefs -
ntfs.
Is it intentional? It's ok if I move them in fs/?
I would leave it
On Mon, Dec 29, 2014 at 04:46:07PM +, Christos Zoulas wrote:
Actually there is also:
- ioctl DIOCGDISKINFO. This is supposed to work for all kinds of
disks but it returns a plist, and it is a pain to use.
Didn't we get something in libutil for calling it? Or am I thinking of
some
On Mon, Dec 29, 2014 at 11:08:27PM +, Michael van Elst wrote:
Actually there is also:
- ioctl DIOCGDISKINFO. This is supposed to work for all kinds of
disks but it returns a plist, and it is a pain to use.
Didn't we get something in libutil for calling it? Or am I thinking
On Tue, Dec 30, 2014 at 02:50:14AM +, Christos Zoulas wrote:
In article 20141229233211.ga10...@netbsd.org,
David Holland dholland-t...@netbsd.org wrote:
It might be a good idea to do this for our own use, but probably it
shouldn't be a 3rd-party interface. (Unless we decide like
On Fri, Feb 13, 2015 at 07:05:00PM +0100, Maxime Villard wrote:
Our norms for significant changes are more or less about consensus or
preponderance of opinion. So far you've said that you want to
remove/disable this, and a number of people have said they use it. No
one else has spoke
On Fri, May 01, 2015 at 07:48:37PM +0200, Joerg Sonnenberger wrote:
On Fri, May 01, 2015 at 01:58:34PM -0300, Leandro Santi wrote:
A quick look at build.sh shows that one of the first things that
needs to be done is to map the MACHINE name to the CPU architecture
name, i.e.
On Fri, May 01, 2015 at 10:17:05AM +0200, J. Hannken-Illjes wrote:
Our miscfs/syncfs originating from the softdep import is a pseudo
file system with one VOP. Its vnodes get used as a kind of marker
on the syncer worklist so the syncer may run lazy VFS_SYNC for
all mounted file systems.
On Fri, May 08, 2015 at 06:00:05PM +0800, Paul Goyette wrote:
I've just noticed that the table in sys/kern/kern_syscall.c is not
generated from the kern/syscalls.master file.
Is there some reason why kern/Makefile isn't used to create the table at
the same time as creating the other
On Sat, May 09, 2015 at 12:25:09PM +0800, Paul Goyette wrote:
Is there some reason why kern/Makefile isn't used to create the table at
the same time as creating the other various syscall-related sources?
All kinds of things about syscalls should be auto-generated that
aren't.
On Mon, May 18, 2015 at 06:40:35AM +0800, Paul Goyette wrote:
My crusade for modularity has arrived at the pcppi(4) driver, and I've
discovered that there are a number of places in the code where a #if is
used to determine whether or not some _other_ driver is available to
provide certain
On Mon, Jun 08, 2015 at 07:18:24PM +0200, Anders Magnusson wrote:
David Holland skrev den 2015-06-08 19:06:
On Mon, Jun 08, 2015 at 04:15:15PM +0200, Anders Magnusson wrote:
printfing from the back of the front end is definitely totally wrong
in other ways that need to be rectified
On Mon, Jun 08, 2015 at 04:15:15PM +0200, Anders Magnusson wrote:
printfing from the back of the front end is definitely totally wrong
in other ways that need to be rectified first :(
Hm, I may be missing something, but what is wrong?
Where should you print it out otherwise?
I would say
On Mon, Jun 01, 2015 at 03:13:32PM -0700, Greg A. Woods wrote:
There's one other thing I ought to mention here, which is that I have
never entirely understood the point of running a modern OS on old
hardware; if you're going to run a modern OS, you can run it on modern
hardware and you
On Fri, Jun 19, 2015 at 05:42:45PM +, Christos Zoulas wrote:
This cv_wait() is tiemout-less and uninterruptible. ioflush will
sleep there forever, holding vnode lock. Any other process doing
I/O on the filesystem will sleep in tstile waiting for the vnode
lock with this path:
On Sat, Jun 20, 2015 at 12:30:28AM +, Christos Zoulas wrote:
Sure. But it also doesn't mean that there should be cases where I/O to
the filesystem hangs uninterruptibly.
Nothing is supposed to hang in tstile; therefore, this wait is
incorrect...
Ok, what is it supposed to do?
On Wed, Jun 24, 2015 at 04:01:24PM -0700, Matt Thomas wrote:
I agree that evb* is confusing and increasingly meaningless and
would like to see us transition away from it.
I contend that moving to sys/arch/cpu is incorrect which there
are multiple MACHINE values for that CPU.
On Thu, Jun 18, 2015 at 11:14:09PM +0200, Edgar Fu? wrote:
1. I was told that kernel halves are not used in NetBSD.
I don't get that. Does NetBSD handle interrupts in a way totally different
from BSD?
bottom halves in the sense used are a linux thing.
--
David A. Holland
On Sun, May 31, 2015 at 11:50:24AM +0100, Justin Cormack wrote:
On 31 May 2015 at 00:09, David Holland dholland-t...@netbsd.org wrote:
I'm saying that, fundamentally, if you want to run gcc4 or gcc5 on a
Sparc IPC that you're going to have problems. There is no way around
this, except
On Mon, Jun 01, 2015 at 02:41:22PM -0400, Andrew Cagney wrote:
To my mind, and I'm assuming a pure SSA compiler design, having SSA
forces issues like: [...]
I'm missing something; SSA is just a style of program representation.
Yes. Lets think of Static Single Assignment as the
On Mon, Jun 01, 2015 at 02:47:39PM -0400, Andrew Cagney wrote:
On 1 June 2015 at 13:50, David Holland dholland-t...@netbsd.org wrote:
but ignoring that -- who (other than apparently the gcc development
team) is focusing on burning ram?
GNU, this is from the GNU coding standard; to me
On Thu, May 28, 2015 at 08:06:56PM +0200, Tom Ivar Helbekkmo wrote:
Me, too. What NetBSD offers, that no other O/S offers, is the support
for platforms that are no longer mainstream. I've run it on Sparc and
VAX processors for years, and hope to continue playing with these old
machines.
On Thu, May 28, 2015 at 05:01:02PM +, paul_kon...@dell.com wrote:
But I too find it regrettable and possibly dangerous. One of my
copious-spare-time projects is to dig up enough specs to add a DECnet
stack to my systems;
DECnet phase IV specs are readily available and good
On Mon, Jun 01, 2015 at 11:41:38AM -0400, Andrew Cagney wrote:
systems and generates reasonable code. Unfortunately, and sorry PCC
(stabs, really?),
Feel free to add dwarf, the source is out there, and it wouldn't be
especially difficult to do it. I just haven't had time.
Stabs
On Sun, May 31, 2015 at 09:24:48PM -0400, Andrew Cagney wrote:
On 30 May 2015 at 19:09, David Holland dholland-t...@netbsd.org wrote:
The reason I floated the idea of forking is that an OS that's
specifically intended to be a high-quality Unix for older hardware can
make a different set
401 - 500 of 795 matches
Mail list logo
