On Thu, Dec 31, 2009 at 01:52:48PM -0600, Frank Zerangue wrote:
Help request -- Mutex(9) indicates that mutex replaces the spl(9) system.
Here are some general (non-NetBSD-specific) answers based on
underlying principles that will hopefully explain the situation better.
(1) When writing an
On Wed, Jan 06, 2010 at 10:51:58PM -0600, Peter Seebach wrote:
You might like to know about apropos(1):
I am told that officially apropos(1) is deprecated, and substituted with
man -k. Which does, in fact, say that it's the same thing.
I think deprecated may mean little more than
On Thu, Jan 07, 2010 at 12:44:07AM -0500, Alex Goncharov wrote:
But:
man -S N STRING
to work, and
man -S N -k STRING
not?...
I think you're looking for man -s, which works fine. I didn't even
know -S existed.
It seems that the problem is that -S is defined
On Thu, Jan 21, 2010 at 10:30:20PM +, Michael van Elst wrote:
IMHO there need to be three different ways to specify block
offsets and block counts:
1. in units of blocks of the physical device
2. in units of blocks of DEV_BSIZE bytes
3. in bytes
Don't forget: 4. in units of the
On Fri, Jan 22, 2010 at 07:38:14AM +, Michael van Elst wrote:
Like most things, there is no universal correct answer here, simply
deciding always use bytes because it seems simpler is unlikely to be
the overall best answer.
I think the suggestion is to use block numbers (or some
On Fri, Jan 22, 2010 at 08:07:03AM +0100, Michael van Elst wrote:
On Fri, Jan 22, 2010 at 05:46:31AM +, David Holland wrote:
On Thu, Jan 21, 2010 at 10:30:20PM +, Michael van Elst wrote:
IMHO there need to be three different ways to specify block
offsets and block counts
On Sun, Jan 24, 2010 at 09:59:09PM +0100, Wolfgang Solfrank wrote:
As an extreme example [on ISO 9660], you could have a file with 3 bytes,
where every byte is in a separate block.
Raising the question of which kind of resource limitation exactly you want
to impose on the user. Wouldn't it
On Sun, Jan 24, 2010 at 08:48:32PM +, David Laight wrote:
The btodb/dbtob macros will need another argument to indicate
where the block size is obtained.
That will just cause massive errors...
For disks I would go for transfer requests (eg from fs) that are either in
fixed units
On Sun, Jan 24, 2010 at 11:21:52PM +0100, Michael van Elst wrote:
Not using DEV_BSIZE requires to change how things work now.
He is right in the long run, though.
You may think that the way NetBSD works is a hack as Izumi Tsutsui
put it. But the argument that keeping things they
On Mon, Jan 25, 2010 at 12:19:30AM +0100, Hubert Feyrer wrote:
On Sun, 24 Jan 2010, o...@linbsd.org wrote:
Fsx is a filesystem exerciser that is used to stress filesystem code.
I would like to propose importing fsx into the base systems, or perhaps
pkgsrc.
The intent is to import
On Tue, Jan 26, 2010 at 07:39:00PM +0100, Manuel Bouyer wrote:
I have a netbsd-3/Xen 2 based server that runs on the same
hardware and we have seen FS corruption in a particular domU on
that system taqt seems to be related to the file system running
out of space. That's what the
On Mon, Jan 25, 2010 at 08:06:11AM +, Michael van Elst wrote:
C hoosing code architectures
'Redesigning' things to fix bugs seems to be common sense
nowadays, as if everything existing is always too bad to be
used.
Of course the same is valid for the redesigned code base in
On Tue, Jan 26, 2010 at 10:39:23AM +, Andrew Doran wrote:
I'm not sure it's as rare as all that; it just mostly doesn't overtly
fail. Instead you end up silently running at a higher IPL than
necessary, and that buys you longer interrupt latencies and more
dropped packets and all
On Sat, Jan 30, 2010 at 08:45:48PM +0100, Frank Wille wrote:
Therefore I would like to change ddb/db_write_cmd.c as in the following
patch:
[...]
Any objections? Do we absolutely need to print the old value here?
I think it's somewhat desirable to. Wouldn't it be better anyway to
On Sun, Jan 31, 2010 at 12:35:16AM +0100, Manuel Bouyer wrote:
Hi,
while investigating directory corruption on my NFS server I found
a possible issue with the buffer cache.
[...]
I think vclean() should also take care of removing the vnode from
the buffer cache's hash. Comments ?
Yes.
On Thu, Jan 28, 2010 at 09:55:53PM +, Mindaugas Rasiukevicius wrote:
Unless anyone objects, I would like to change struct
uvm_object::vmobjlock to be dynamically allocated with
mutex_obj_alloc(). It allows us to: 1) share the lock among
objects by holding a reference 2) avoid
On several occasions it's been suggested that lfs should be unhooked
from ufs, on the grounds that sharing ufs between both ffs and lfs has
made all three entities (but particularly lfs) gross. ffs and lfs are
not similar enough structurally for this sharing to really be a good
design. Nobody I've
On Sun, Feb 07, 2010 at 10:10:31AM +, Mindaugas Rasiukevicius wrote:
The copy involves 18 files from sys/ufs/ufs (out of 21; the ones
excluded are quota.h and unsurprisingly ufs_wapbl.[ch]) which contain
9067 lines of code. That gives the following statistics:
14988 size
On Sun, Feb 07, 2010 at 11:07:55AM +, Mindaugas Rasiukevicius wrote:
It was discussed months ago. This is a reminder/heads-up.
Where? This mailing list is a right place where such discussions (and
decisions) should happen.
Right here...
--
David A. Holland
dholl...@netbsd.org
On Tue, Feb 02, 2010 at 10:53:58PM +0100, Manuel Bouyer wrote:
I found the cause of for this one:
[...]
To fix this I propose to have ffs_trucate() (and derivatives) always set
v_writesize, even if the real size of the inode didn't change.
The attached patch completely fixes the test
On Wed, Mar 03, 2010 at 09:27:43PM +0100, Manuel Bouyer wrote:
Anyone has commnts about this ? I'd still like to hear some from
UVM/UBC experts ...
Should this be pulled up to -4? It applies cleanly and I can probably
test it (some...)
Yes, it's also needed for -4 (AFAIK
On Wed, Mar 03, 2010 at 03:26:20AM +0900, Masao Uebayashi wrote:
I want to slowly start breaking down config(5) files
(sys/conf/files, sys/**/files.*) into small pieces. The goal is to
clarify ownership of files; lines like file aaa.c bbb | ccc are
to be changed into file aaa.c
On Mon, Feb 22, 2010 at 04:40:58PM -0500, Matthew Mondor wrote:
After reading the manual page of msync(2), I have the impression that
if invoked with the MS_SYNC flag, it should be safe enough not to need
a further fdatasync(2)/fsync_range(2) call afterwards?
That is the theory.
And how
On Fri, Mar 05, 2010 at 01:14:50AM +0900, Masao Uebayashi wrote:
Perhaps a first step would be using config(1) and files.* to generate
the module makefiles instead of maintaining them by hand...
cube@ said he did this part long time ago. The thing is that only
fixing these tools
On Mon, Mar 08, 2010 at 10:53:16AM +0200, Antti Kantee wrote:
(FFS_EI isn't the only such option either, it's just one I happen to
have already banged heads with.)
This one is easy, no need to make it difficult.
Sure, but as I said it was just an example; what about the next one?
On Wed, Mar 10, 2010 at 11:47:49AM +0900, Masao Uebayashi wrote:
I wonder what is the best design / implementation of devfs.
none
When you go and do it right it turns into some automount logic and a
tmpfs.
--
David A. Holland
dholl...@netbsd.org
On Thu, Mar 11, 2010 at 01:36:41AM +0900, Masao Uebayashi wrote:
Well, yes. ?But research efforts are like that. ?Robustness is pretty
much necessary for production use but not for the stage this appears to
be at.
I'm not a researcher. I'm an engineer. I like steady move
On Sun, Mar 14, 2010 at 03:33:19PM +0900, Masao Uebayashi wrote:
I did; bus attachments.
If you pay a little more respect to engineers, you'll find this is
almost same as Iain's saying and what I wrote in the first mail.
huh? he asked me what I meant, I said what I meant...
--
David
On Sat, Mar 13, 2010 at 08:02:51AM -0500, der Mouse wrote:
[st_dev] does not have to correspond, though, to anything else in
the system.
Not really, no, but it may as well be the same as what's in st_rdev.
If there still is an st_rdev. I see no particular reason that needs to
be
On Tue, Mar 16, 2010 at 06:50:29PM +0100, Zafer Aydo?an wrote:
I'm wholeheartedly behind Julio's statement.
Users should never have to rebuild anything.
Er, why?
Users should never have to perform complex unautomated procedures,
because such procedures can easily be screwed up and recovery
On Wed, Mar 17, 2010 at 07:48:32PM +0100, Edgar Fu? wrote:
DH Nor is it necessarily slow; building a kernel doesn't take any longer
DH than booting Vista...
EH Maybe on your machine. On mine it's still quite a bit slower than just
EH editing a config file.
Which gives you a totally new
On Wed, Mar 17, 2010 at 11:10:59AM -0500, Eric Haszlakiewicz wrote:
On Tue, Mar 16, 2010 at 08:01:31PM +, David Holland wrote:
But recompiling things isn't a complex unautomated procedure, it's a
complex automated procedure, and not really that much different from
other complex
On Sat, Mar 20, 2010 at 01:54:49PM -0400, Elad Efrat wrote:
Thor Lancelot Simon wrote:
If not, I don't think this adds any benefit to your proposal and is likely
to simply be a distraction; I'd urge you in that case to drop it.
Strongly seconded. There are so many great ways to improve NetBSD
On Sat, Mar 20, 2010 at 12:40:12PM -0400, Thor Lancelot Simon wrote:
As a part of my work I would like to write a translator for C
language and a small library. Their goal would be to detect
integer overflows, stack overflows, problems with static array
indexing, etc (when such occur
On Sat, Mar 20, 2010 at 10:29:44PM +1030, Brett Lymn wrote:
I have given up on suspending because my filesystems would be
corrupted with monotonous regularity. The chances of a corruption
seems to increase with the amount of disk activity happening on
suspend. It seems like something is
On Sat, Mar 20, 2010 at 03:40:33PM -0400, Elad Efrat wrote:
If not, I don't think this adds any benefit to your proposal and
is likely to simply be a distraction; I'd urge you in that case
to drop it.
Strongly seconded. There are so many great ways to improve NetBSD and
wasting time
On Sat, Mar 20, 2010 at 04:06:32PM -0400, Steven Bellovin wrote:
That suggests that something is flushing buffers to a device that's
suspended and it's throwing them away instead of rejecting them or
panicing.
Possibly
Although it doesn't quite make sense, because in most cases
On Sat, Mar 20, 2010 at 05:03:16PM -0400, Steven Bellovin wrote:
Let me see if I can find my first note on the subject -- it might
give a clue about the date of any changes.
Turns out that I sendpr-ed it in September: kern/42104.
I even responded to the PR, not that I had any useful
On Thu, Mar 25, 2010 at 01:14:51AM +0900, Masao Uebayashi wrote:
? (Besides, it's not necessarily as flat as all that, either.)
?
? It's necessary to be flat to be modular.
Mm... not strictly. That's only true when there are diamonds in the
dependency graph; otherwise, declaring
On Fri, Mar 19, 2010 at 02:49:37PM +, Andrew Doran wrote:
I *do* think it's a useful datapoint to note that sun2, pmax, algor, etc.
are never, ever downloaded any more.
Right, and these dead ports must be euthanized. The mountain of
unused device drivers and core kernel code is a
On Thu, Mar 25, 2010 at 06:22:17PM +0900, Masao Uebayashi wrote:
% grep ':.*,' sys/conf/files | wc -l
86
And? I don't understand your point. There are a lot more than 86
entities in sys/conf/files.
There are many instances where modules have multiple dependencies.
On Fri, Mar 26, 2010 at 10:24:02AM +0900, Masao Uebayashi wrote:
(Honestly, I see benefit to not convincing you; objection only from
dholland@ sounds more convincing to me than no objections.)
Um. I'm sorry you think that. I guess there is no point continuing
this discussion, then. Or much of
On Fri, Mar 26, 2010 at 01:45:51PM +, Andrew Doran wrote:
I'm speaking of low level kernel code and driver drivers, areas that to
date you have had relatively little involvement in.
That's not entirely true, but fair enough.
I will however consider discussing the points you raise
On Thu, Apr 15, 2010 at 08:40:19AM +, David Holland wrote:
Wish we had working $ORIGIN...
We will fairly soon, I think... :-)
To wit: as far as I can tell, having been wading around in that code
recently, the only problem with what we have is that if the path sent
back by namei isn't
On Wed, Apr 21, 2010 at 08:58:31AM -0400, Christos Zoulas wrote:
| Is it reasonable to just do that? I don't think calling getcwd() from
| exec is going to cause locking problems, but it might be more overhead
| than we want to swallow.
The code that we have there works fine now, yamt
On Wed, Apr 21, 2010 at 01:22:12PM -0400, Christos Zoulas wrote:
| If you exec ../bin/foo, that's all namei will resolve or touch, and
| that's the string that'll come back from namei. If we want an absolute
| path out, it needs getcwd, either in exec or in namei... and in exec
| is
On Fri, Feb 19, 2010 at 06:42:03AM -0500, der Mouse wrote:
I'd say it's a question of whether you think of them as input to the
kernel, commands (enable this), or as output from the kernel,
reporting state (this is enabled).
Of course, in most cases, they're actually both, so that
On Wed, Apr 28, 2010 at 02:57:47PM -0400, der Mouse wrote:
To wit: as far as I can tell, having been wading around in that code
recently, the only problem with what we have is that if the path
sent back by namei isn't absolute it needs a getcwd() stuck on the
front of it.
Is it
On Tue, Jun 01, 2010 at 08:31:56AM -0400, der Mouse wrote:
It happens even when I try to boot to single user mode because I see
the message saying /: replaying log to memory right before it
panics. Not sure why the journaling stuff happens when booting in
single user mode without
On Wed, Jun 02, 2010 at 05:58:40PM +0100, David Laight wrote:
In the long term VOP_xxxLOCK() should become part of the file systems.
AFAIK there is a consensus between yamt@, ad@ and thorpej@ that
locking should be moved down to the filesystems.
There was some discussion about it
On Tue, Jun 01, 2010 at 11:44:03AM +0200, Juergen Hannken-Illjes wrote:
It's not immediately clear how either of these ought to work, so
I'm concerned that making the infrastructure less general will
lead to problems.
1) One upper to many lower vnodes
This is a file system like
On Mon, Jun 21, 2010 at 06:23:02PM -0400, Christos Zoulas wrote:
Well, I find the different indentation styles typically use for the braces
clumsy and not following the standard. Or even when they do, they cause the
code to move too much to the right:
FWIW, I prefer this:
switch (c) {
On Sat, Jun 26, 2010 at 10:39:27AM +0200, Juergen Hannken-Illjes wrote:
The vnode lock operations currently work on a rw lock located inside the
vnode. I propose to move this lock into the file system node.
This place is more logical as we lock a file system node and not a vnode.
This
On Sun, Jun 27, 2010 at 06:18:19PM +0200, Juergen Hannken-Illjes wrote:
(In the absence of some clear benefits I don't think it's a
particularly good idea to paste a dozen or two copies of genfs_lock
everywhere. But folding vcrackmgr() into genfs_lock and genfs_unlock
seems like a fine
On Thu, Jul 01, 2010 at 05:18:36AM -0700, Paul Goyette wrote:
b) a way to pause long enough to manually transcribe the output? (A
simple timed delay would work, although a Press any key to continue
would be easier!)
It may work to do
printf(Press a key...\n);
cnpollc(1);
On Sat, Aug 14, 2010 at 01:36:15PM +0200, Jean-Yves Migeon wrote:
I would say don't do __func__ for messages like this; it doesn't
really serve much purpose vs. typing in a name, causes the observable
behavior to change silently if the code gets reorganized, and makes it
much harder to
On Tue, Oct 12, 2010 at 12:53:10AM -0300, Lourival Vieira Neto wrote:
A signature only tells you whose neck to wring when the script
misbehaves. :-) Since a Lua script running in the kernel won't be
able to forge a pointer (right?), or conjure references to methods or
data that
On Sat, Oct 16, 2010 at 11:23:29AM +0900, Izumi Tsutsui wrote:
It would seem to be intentional. After all, kernel modules can
do all sorts of nasty things if they want to.
In that case, module autoload/autounload is not functional at all and
we have to specify all possible necessary
On Sun, Oct 17, 2010 at 03:38:42AM +0900, Izumi Tsutsui wrote:
Heh, then why have we had it on i386 for years?
Because of the X server.
You are just saying:
We introduced a significant security regression just for our own
convenience.
Perhaps...
I see no proper reason to
On Sat, Oct 16, 2010 at 12:03:52PM -0700, Paul Goyette wrote:
autoload/autounload does NOT perform any authorization checks -
please look at the code! No checking of securelevel occurs, as far
as I can see. For autoload, the module name must not contain a
'/', so if the module is
On Sun, Oct 17, 2010 at 06:13:11AM +1100, matthew green wrote:
...and I'm not convinced of this, primarily because (from a practical
point of view) X is unavoidable and unfixable, whereas modules are
neither.
actually, with DRM (and KMS) i believe we will be able to run the
X
On Mon, Oct 25, 2010 at 05:49:11PM +0100, David Laight wrote:
No, since in general the file is also being extended (certainly in
this case it is) it also has to lock the file size, and that's going
to deny stat() until it's done.
A stat request during a write can safely return the
On Mon, Nov 01, 2010 at 08:00:09PM -0500, David Young wrote:
I'm working on a library called ppath(3) for making property lists more
convenient to use in the kernel. With ppath(3), you refer to a property
to read/write/delete in a property list by the path from the list's
outermost
On Wed, Nov 03, 2010 at 09:28:11AM +0100, Martin Husemann wrote:
This is one of the ocassions where I would love to use C++ and templates
in the kernel ;-}
I think what you mean is that you'd like to have a language that has
some kind of sane parameterized types... :-/
--
David A. Holland
On Fri, Nov 12, 2010 at 02:21:34PM +0100, Johnny Billquist wrote:
then I realized that this solution would break if people actually
wrote code like
lock(a)
lock(b)
release(a)
release(b)
...which is very common.
It is? I would have thought (and hoped)
On Fri, Nov 12, 2010 at 08:31:39PM +, Eduardo Horvath wrote:
No it doesen't because all those macros assume the value is being
transferred from one register to another rather than regiser to memory.
The assignment:
foo.size = htole64(size);
Cannot be replaced with:
On Sat, Nov 13, 2010 at 01:45:40AM +0900, Izumi Tsutsui wrote:
Wow. I guess you can add me to the list of people leaving.
There is no perfect world and we don't have enough resources.
Any help to keep support for ancient machines are appreciate, but
complaints like we should support
(moving this to tech-kern because it's the right place and per request)
On Mon, Nov 15, 2010 at 11:24:21AM +0900, Masao Uebayashi wrote:
Every header file should include the things it requires to compile.
Therefore, there should in principle be no cases where a header file
(or source
On Mon, Nov 15, 2010 at 10:41:55PM +, David Laight wrote:
Indeed. Properly speaking though, headers that are exported to
userland should define only the precise symbols that userland needs;
kernel-only material should be kept elsewhere.
One start would be to add a
On Mon, Nov 15, 2010 at 03:47:32PM -0500, der Mouse wrote:
[...] just forward declarations of the structs.
(this is, btw, one of the reasons to avoid silly typedefs)
I'm not sure what typedefs have to do with it. typedeffing a name to
an incomplete (forward) struct type works just
On Sat, Nov 20, 2010 at 07:50:03PM -0800, John Nemeth wrote:
} embed the property info in the module file itself?
That may or may not make more sense, but it would require a lot
more work (i.e. inventing a tool to extract them, edit them, and insert
them; and modifying the module
On Tue, Nov 23, 2010 at 11:13:02PM +, David Holland wrote:
However, I discovered today that rumpfs's VOP_LOOKUP implementation
relies on being able to access not just the name to be looked up, but
also the rest of the pathname namei is working on, specifically
including the parts
On Wed, Nov 24, 2010 at 01:26:04PM -0500, der Mouse wrote:
Right. But if you want a guaranteed absolute path you should be able
to do it by calling getcwd first.
Only if you accept breakage if the current directory no longer has any
name.
Well, if you can't call getcwd, then it won't
On Wed, Nov 24, 2010 at 08:30:18PM +0200, Antti Kantee wrote:
I think it makes more sense for doregister to check for at least one
leading '/' and remove the leading slashes before storing the key.
Then the key will match the name passed by lookup; otherwise the
leading slash won't be
On Sun, Nov 28, 2010 at 09:47:02PM +, David Holland wrote:
(Also, why a radix tree? Radix trees are generally not very efficient.
If you're going to, though, you might want to reuse the direct,
indirect, double indirect, etc. method FFS uses for block mapping.)
...and the easiest way
On Sun, Nov 28, 2010 at 11:43:48PM +0100, Joerg Sonnenberger wrote:
A radix tree is kind of a bad choice for this purpose. The easiest
approach is most likely to have [a btree]
I would go with an expanding hash table of some kind, e.g. size is 2^n
pages, hash (2^n - 1) tells you the page to
On Mon, Nov 29, 2010 at 11:12:21AM -0500, der Mouse wrote:
Without any real data on what UID distribution looks like in practice,
we're all speculating in a vacuum here.
Just for shits and giggles I ran this on a real password file with
about 350 users that's had lots of churn since it was
On Tue, Dec 14, 2010 at 08:49:14PM -0800, Matt Thomas wrote:
I have a fairly large but mostly simple patch which changes the
stats collected in uvmexp for faults, intrs, softs, syscalls, and
traps from 32 bit to 64 bits and puts them in cpu_data (in
cpu_info). This makes more accurate and
Because we have at least one FS that may not want paths being looked
up to be split on '/', namely rump etfs, and arguably the most
important simplification to VOP_LOOKUP is to make it handle one path
component at a time, we need a way for a FS to decide how much of a
path it wants to digest at
On Sun, Jan 02, 2011 at 09:19:30AM -0500, matthew sporleder wrote:
[TRYEMULROOT]
Since it's on http://www.netbsd.org/~dholland/buglists/file.html , I'm
sure you're aware of it, but would 41678 be solved?
http://gnats.NetBSD.org/cgi-bin/query-pr-single.pl?number=41678
Doubtful, as
On Sun, Jan 02, 2011 at 06:14:57PM +, David Laight wrote:
On Sun, Jan 02, 2011 at 09:52:31AM +, David Holland wrote:
Has anyone ever sat down and clearly worked out the desired semantics
for TRYEMULROOT? I've noted inconsistencies in the past, and because
in a number of ways
On Sun, Jan 02, 2011 at 10:48:03AM +, David Laight wrote:
On Sun, Jan 02, 2011 at 09:17:11AM +, David Holland wrote:
Because we have at least one FS that may not want paths being looked
up to be split on '/', namely rump etfs, and arguably the most
important simplification
On Sun, Jan 02, 2011 at 09:19:51PM +, Eduardo Horvath wrote:
TRYEMULROOT should only open existing objects on the emul path, it should
never create anything new, so you would never want to use it for mkdir.
I don't know if that means you need to pass an extra flag to
namei_parent()
On Mon, Jan 17, 2011 at 04:33:25PM +0100, Manuel Bouyer wrote:
so I'm evaluating how to use proplib for the new quotactl(2) I'm working on.
er, why? When I was looking at quota stuff in the context of lfs and
other fs types, the existing quotactl interface seemed fine -- it just
needs to have a
On Tue, Jan 18, 2011 at 04:24:37PM +0100, Joerg Sonnenberger wrote:
Well, we derive the version to include from the version file. This is
controlled by a central script. What about adding support to expand
$DATE$ or some other magic version string, if it is the last in the
version file? If
On Tue, Jan 18, 2011 at 09:39:58PM +0100, Joerg Sonnenberger wrote:
That's unnecessarily complicated. There's prior art for this:
[...]
Please look at the mail that started this threat. newvers provides
multiple independent variable, so conditionally providing one of them
needs
On Mon, Jan 31, 2011 at 05:40:20PM +0100, Matthias Drochner wrote:
PR 44496 notes that COMPAT_386BSD_MBRPART is still enabled in
disklabel(8), even though it was turned off by default in the kernel
early in 4.99.x. The PR also notes that it's not harmless to leave it
on.
The PR
On Sat, Feb 05, 2011 at 10:07:13PM -0500, der Mouse wrote:
Of course, still better would be to fix vnd, though I'm not sure what
the right fix would be.
What's the problem? My vague understanding was that you could get into
deadlocks allocating blocks, but maybe I'm confusing it with
On Thu, Feb 03, 2011 at 08:04:26AM +, David Laight wrote:
The PR rather leads to the conclusion that the support for
old Partition IDs in disklabel(8) is suboptimal.
Originally, the code did only consider a partition with the
old ID if no new one was found. This apparently got
On Mon, Feb 07, 2011 at 01:48:57AM -0500, Thor Lancelot Simon wrote:
For the record, I am pretty sure it was sysinst, not disklabel, which
hosed my disk. Sysinst compiles equivalent code in directly, no?
There are only two uses of MBR_PTYPE_386BSD in src/distrib. One is a
perfectly innocuous
On Sun, Feb 13, 2011 at 01:06:36PM -0500, Thor Lancelot Simon wrote:
Not in the failure case I observed (I can now reproduce this, but since
it looks like the code in disklabel is going to Go,
It has Gone :-)
(The remaining question is whether to request pullup to -5; I think I
will unless
On Wed, Mar 02, 2011 at 12:40:44AM +, Andrew Doran wrote:
With modules now basically working we should either retire or move
some of these items to pkgsrc so that the interested parties maintain them.
An awful lot of the compat stuff is now very compartmentalised, with not
much more
On Sat, Feb 19, 2011 at 11:21:35PM +0100, Manuel Bouyer wrote:
I think the code in the bouyer-quota2 branch is stable now, and
ready to be merged to HEAD. Unless objections, I'll merge it in
about 2 weeks.
[...]
So, I thought one of the points of this was to make the quota
interface
On Wed, Mar 09, 2011 at 08:20:00PM +0100, Manuel Bouyer wrote:
On Wed, Mar 09, 2011 at 06:28:11PM +, David Holland wrote:
struct quota2_entry (and so struct quota2_val) is used for both
on-disk storage, and in-memory representation in tools and kernel.
I agree this should
On Mon, Mar 21, 2011 at 02:21:26PM +0100, Manuel Bouyer wrote:
(also, edquota and repquota seem fs-independent to me...)
no, they're not: they can directly the quota1 file specified in the
fstab if quotactl fails or the filesystem is not mounted.
That's a bug, or more accurately legacy
(more context restored)
On Wed, Mar 23, 2011 at 09:51:48AM +0100, Manuel Bouyer wrote:
(also, edquota and repquota seem fs-independent to me...)
no, they're not: they can directly the quota1 file specified in the
fstab if quotactl fails or the filesystem is not mounted.
That's a bug,
On Wed, Mar 23, 2011 at 09:50:16AM +0100, Manuel Bouyer wrote:
On Wed, Mar 23, 2011 at 03:44:53AM +, David Holland wrote:
On Tue, Mar 22, 2011 at 05:41:52PM +0100, Manuel Bouyer wrote:
| (also, edquota and repquota seem fs-independent to me...)
|
| no, they're
On Wed, Mar 23, 2011 at 02:18:55PM +, Mindaugas Rasiukevicius wrote:
I would like to split-off parts of vfs_subr.c into vfs_node.c * and
vfs_mount.c modules. Decomposing should hopefully bring some better
abstraction, as well as make it easier to work with VFS subsystem.
On Thu, Apr 28, 2011 at 12:02:51PM +0200, Edgar Fu? wrote:
Is there a saner way of reading non-standard (e.g., 10 sectors per track)
floppies than either
a) building a custom kernel with modified fd_types in sys/dev/isa/fd.c
b) writing a user-space program that sets the appropriate
On Mon, May 02, 2011 at 03:23:48PM +0200, Manuel Bouyer wrote:
unfortunably I don't have a core dump (I couldn't get one).
And unfortunably it's not reproductible with a simple testbed (I've been
trying for 3 days).
I wonder if it could be related to the INRENAME change that has
been
1 - 100 of 791 matches
Mail list logo
