I don't know if anyone recalls enough 4.x to say anything useful here,
but if anyone does and cares to comment
The machine: 4.0.1 i386. Two CPUs. (Kernel has MULTIPROCESSOR,
MPBIOS, and APM_NO_IDLE turned on.)
NFS-mount a filesystem with a big (half-terabyte) file in it. vnconfig
that
I was under the impression that vnconfigging an nfs-mounted file
continues to not work to today -- [...]. In other words, Don't do
that.
Okay. I juggled things around a bit, so the vnconfig and mount were
done on the NFS server instead, with the vnd mount point exported.
Then, while adding
That what it is reasonable for a disk to do consensus *is* the
interface spec I was talking about, not the de-jure non-spec of you
get whatever the device (via its driver) feels like giving you.
That's sort of the point. If you want what it is reasonable for a
disk to do you should be using
This would mean that raw devices as interfaces to disks are
essentially useless.
Not at all, as history has proven, as that's what the rule has always
been.
Only because
[I]n the real world, the manufacturers don't make products that they
can't sell, and people don't buy products that
[...], there's a lot of history behind the notion that userland
alignment of write() buffers affects, at most, performance, to the
point where I consider it part of the interface.
Not on access to raw devices it isn't, and never was - what Erik Fair
said [...] was 100% correct - if you're
I've just run into something (on 4.0.1) which looks to me as though
write() buffer alignment matters. This sounds to me like a bug, but it
appears to have something to do with the hardware, and I'd appreciate
any thoughts on how I might best track it down.
I tried to run one of my tools (a disk
It does, however, appear to have something to do with the hardware
[...]
It's most likely the controller hardware (or firmware). The driver
doesn't seem at all interested in the data alignment, and I don't
recall other parts of the I/O stack caring.
That sounds reasonable.
To verify you
It's a 53c8xx: we load the firmware into it from our own driver.
I just had a look at esiop.ss, and it looks high-level enough that it's
plausible to me that the problem is with whatever's backing that code,
whether silicon or ROMed firmware or whatever.
I've sent an email to the relevant
It's a 53c8xx: we load the firmware into it from our own driver.
I just had a look at esiop.ss, and it looks high-level enough that
it's plausible to me that the problem is with whatever's backing
that code, whether silicon or ROMed firmware or whatever.
I just verified that I see the same
%ps -uw28755
USER PID %CPU %MEM VSZ RSS TTY STAT STARTEDTIME COMMAND
buhrow 28755 0.1 0.0 408 932 ? S24May11 0:03.27 sshd: buhrow@ttyp2
%whoami
buhrow
%ktrace -p 28755
ktrace: file ktrace.out, pid 28755: Operation not permitted
See sys/kern/kern_ktrace.c. This is probably
So, what's the advantage of a larger sectPerSU?
Larger is not necessarily better. Larger than the typical write size
(which is usually the filesystem block or frag size) is actually a
*dis*advantage, because it means that common writes force RMW cycles.
Much smaller than the typical access
[...], as local SOCK_DGRAM sockets will return ENOBUFS when kernel is
out of buffer memory. As I understand, there is no way to sleeep
instead.
I've never investigated it in detail, but my understanding is that
that's the usual semantic for SOCK_DGRAM.
I thought this was specific to
I'm not sure what happens for blocking datagram sockets.
The historical practice is that they're best effort: writing never
blocks. Some conditions responsible for packet drop are reflected in
the write()/send()/etc return value; others aren't - though I think for
AF_LOCAL they're all the
Putting that aside for a moment, let's pretend we had a stream socket
in this application instead of a datagram one. I think the right
thing to do at that point would be to add a killpeer() syscall, which
sends a signal to the other process associated with a file
descriptor.
With what
ffsv1 or v2? [...]
I suspect this is not about UFS1 vs UFS2 but FFS1 (as obtained by
newfs without -O) vs FFS v2 (as obtained by newffs -O 2).
Okay, now I'm confused.
What is the difference between UFS1 and UFS2, and what is the
difference between FFS v1 and FFS v2? I've been thnking they
What is the difference between UFS1 and UFS2, and what is the
difference between FFS v1 and FFS v2?
As I understand, FFS sits on top of UFS.
That could be part of my confusion, then. Speaking strictly from a
personal-experience historical perspective, FFS was the Berkeley Fast
File System,
The problem is that there might be some ports whose MAXPARTITIONS is
still 8 and such ports can't use type 8.
Nothing says fd.c has to use MAXPARTITIONS (nor the macros built using
it) when breaking up the device minor number.
/~\ The ASCII Mouse
\ / Ribbon Campaign
then, after replacing the failed sd0 with the new sd0
But with scsictl detach/scan, I suppose?
If that's an excerpt from me: no.
I've done this several times with non-hotpluggable SCSI hardware
where I had to power off anyway.
I've done it with non-hot-pluggable hardware _without_ powering
[Please don't use paragraph-length lines for normal text!]
I have a RAID1 consisting of sd0a and sd1a. Now, sd0 sometimes fails
with hardware error, but reconstruction onto it is OK. Of course,
I want to replace the disc. Luckily, I have a spare drive and
everything is hotpluggable SCA and
None of these can help with that. Whenever as your RAID1 is running
single-member, you lose it if the live member fails.
Yes, of course.
But it's currently running 2-member. Is there a way to temporarily
run it three-member and then remove the error-prone component?
Oh, I see what you
[...] doxygen [...]
As regards doxygen: ow.
Quite.
Have you ever actually tried to run a nontrivial part of the NetBSD
tree through doxygen?
No.
I have, however, tried to use doxygen-generated documentation for
various other projects (this from the days when I was hacking on some
Android
((b * 0x80200802ull) 0x0884422110ull) * 0x0101010101ull 32
((b * 0x0802u 0x22110u) | (b * 0x8020u 0x88440u)) * 0x10101u 16
Maybe. Do all machines NetBSD still cares about have fast-enough
multiply instructions? Unless the multiply is unusually fast compared
to shift and mask
[tls]
The issue involves the way we arranged for binary compatibility
across changes in the unix-domain file descriptor and credentials
passing code. [...]
I would appreciate others' opinions on this.
Here's scm-rights.h from one of my SCM_RIGHTS-using programs.
I think the comments say it
I think that the sparseness check should stay until vnd supports
sparse files.
It already does, under some circumstances (eg, NFS-remote).
I _would_ prefer to see an override for cases like NFS, or where the
values returned trip the test even though the file is not sparse in the
sense vnd
pci_device_is_boot_vga()
[...]
While X is probing the pci devices the driver enables all pci vga
devices. That is why checking for the 'firmware enabled' one fails.
But checking for the firmware-enabled one is a broken idea. There
may fewer or more than one such, for one thing - nothing
Except that tells me whether the kernel being booted is recent, not
whether the bootloader doing the booting is.
No. It is the version in src/sys/sys/param.h. It doesn't have any
relation to the kernel you are running or booting.
Oh, that kernel version! That it is of no use for my
True. What I use the timestamp for (when I use it at all, that is)
is answering is the bootloader (or whatever) I'm getting the one I
just built and think I installed, or did something go wrong?. The
difference between ten minutes old and two weeks old is important;
the difference between
[...], but I wonder if there is any point in keeping the date [in the
bootloaders]
Personally, I find it useful to make sure I've got the bootloader I
think I do installed, usually after a change-and-rebuild. Wait a
minute, this one was built two months ago, not ten minutes ago; what
went
[...], but I wonder if there is any point in keeping the date [in
the bootloaders]
Personally, I find it useful to make sure I've got the bootloader I
think I do installed, usually after a change-and-rebuild. Wait a
minute, this one was built two months ago, not ten minutes ago; what
went
No. The existance of ASIDs along with the hardware implementation is
fundamentally a proprty of the MMU design. Exposing this information
outside of the MD code base (pmap(9)) breaks encapsulation.
In detail, yes. In general, no.
I haven't looked at the ASID issue in detail. But it sounds
There is a bigger problem, the 'int' and 'void *' arguments might be
passed in different ways then '...' is specified.
True, but it is not inherently a problem; it just complicates the
implementation of ioctl(), since it then has to not just pass down a
data pointer, but pass down enough
int ioctl(int, unsigned long, ...);
Most of our ioctl's take pointer arguments. Some streams ioctls
though take int arguments (ioctl(fd, I_FLUSH, FLUSHR) for example)
and using void * as the argument would not compile cleanly.
Must FLUSHR (to continue your example) be defined as an
[...] but as I understand it, the [NFS] server implements its own
limits, not the client, which is as it should be.
The server should enforce limits if it is configured to have them, yes.
But the only reason I can see why the client shouldn't also be able to
put quotas on an NFS-mounted
(Note that this is free -- it would require splicing a getcwd into
every namei call.)
_Not_ free, I assume you mean?
er right, silly editor... :-/
:-รพ I've had that happen to me often enough.
Anyway, it looks as if it's not needed.
Just as well. It has (since) occurred to me that it
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.
Of course, if you consider that acceptable, then fine. I don't, not
for something as central as namei (though
Every header file should include the things it requires to compile.
I've long felt this way: that, except for a very few examples like
assert.h that are defined to depend on context, the order of
#includes should not matter. In particular, if multiple files must be
included, any of them may
I've long felt this way: that, except for a very few examples like
assert.h that are defined to depend on context, the order of
#includes should not matter. In particular, if multiple files must
be included, any of them may come first - so any file that generates
errors if it's included
Just a note to avoid having incorrect information in the archives
without a correction. I wrote:
[%] It occurs to me, the VAX's BBSSI and BBCCI _are_ CAS, just
restricted to a one-bit-wide operand (and with the data-to-swap-in
specified by choice of instruction rather than an operand).
This
Hadn't it been much nicer of we just had the mutex and lock
abstraction, and left the whole implementation to each MD part?
Exactly. Consider this hypothetical:
x86 does #define ATOMIC_OPS_USE_CAS and defines a CAS(); MI code
notices this and defines all the higher-level primitives (if that's
Already wrote about reasoning in other reply to mouse (keywords: no
code duplication, better design), so wont repeat myself.
Except you appear to think that the only options are the current state
and each arch totally doing its own thing.
There are places other than those two to draw the
It is not about mainstream. Please tell me one architecture that has
been created in the last 10 years, supports at least 32bit address
space, virtual memory and doesn't support either CAS or LL/SC.
What's that got to do with it?
NetBSD used to be about proper separation between MI and MD so
Exactly! And I would like to emphasize that this has nothing to do
with breaking of MI and MD abstraction or x86-centric view.
Yes, I imagine you would. But it's still false.
Decision was to provide CAS abstraction [sic!] as a primitive for MI,
by the MD land - in a same way, like we have
The only right way to retrieve P-V translation is to lookup from
vm_map (== the fault handler).
What about setting up DMA on machines whose DMA uses physical
addresses? Or does the DMA code get an exception to this rule?
I also suspect debugging may well be a non-ignorable use case, though I
proc.curproc.rlimit.memorylocked.soft = 697976149
With all of the above set, for some reason it's not possible to lock
more than 666MB.
Well, 697976149 bytes is 665.6419+ MB, so it sounds to me as though
it's doing exactly what it should be.
Unless you're a disk manufacturer, in which case
This is the other main difference to OF: on ports using OF, it is
always available. ACPI on i386 is not (yet).
It's not quite as simple as ports using OF and ports not using OF.
For example, while I have personal experience with only the one unit,
I have a situation in which it would be useful to run SLIP on a serial
console. Obviously, this won't work very well at present. (The
machine has only one serial port and no useful network interfaces.)
I was looking at improving if_sl.c to support encapsulating normal
serial data on the SLIP's
I have a situation in which it would be useful to run SLIP on a
serial console. Obviously, this won't work very well at present.
(The machine has only one serial port and no useful network
interfaces.)
Maybe something like SLIRP (http://en.wikipedia.org/wiki/Slirp)?
Haven't used it in aeons
I have a situation in which it would be useful to run SLIP on a
serial console. [...]
Given how rare the situation is, maybe it's best to do the
encapsulation/decapsulation in user mode, and feed into SLIP via a
pty. (I also suspect that the speeds are low, but I know you often
run older
I was looking at improving if_sl.c to support encapsulating normal
serial data on the SLIP's tty as packets, [...]
I've encountered that on a serial protocol in my Arduino work. It
worked quite well i have to say. It worked due to a packet starting
with an unique byte. [...]
I don't know
I wonder if you would need this kind of console even for ddb work.
Well, I want it to work for direct kernel-user interaction; ddb is an
example of that, but so are pre-single-user things such as userconf and
printing autoconf output.
If you need console for ddb, things get messy.
Indeed they
POSIX.1e capabilities are actually coarse-grained OS privileges,
Not all that coarse-grained as compared to traditional Unix privileges!
[POSIX-style capabilities] solve (or, in some cases, don't solve)
an orthogonal problem in UNIX security: how to decompose root
privilege.
Not all that
total memory = 2047 MB
avail memory = 1999 MB
total memory = 256 MB
avail memory = 239 MB
Some graphics chips, especially on lower-end machines, use main
memory, thus making it unavailable to the CPU.
It's not that simple. I've seen this for a very long time, including
on machines with no
Is there a way to open a directory on which you have neither read nor
write access (maybe not even search access) ?
I've thought for some time there sbould be an O_NOACCESS, to open
things without any ability to do I/O. The major use for this I've
found is opening directories for later feeding
Fix a 16 year old bug in the sorting routine for non-contiguous netmasks.
Does our IPSEC code actually _use_ non-continguous netmasks?
I haven't looked at the IPsec code, so this is a guess, but the wording
makes it sound as though this is an implementation technique used
internally by IPsec
On the other hand, simple non-contig netmasks, with no ambiguity,
certainly were permitted originally. They work just fine. They also
offer essentially nothing over contig netmasks - they're just a
permutation of the bits in the addresses.
I wouldn't say _nothing_. See below.
The one
I believe that non-contiguous netmasks actually are illegal nowadays.
Cite?
They became illegal when CIDR was implemented.
Implemented? I doubt it. Standardized, at most. But even then, it
would take years to eliminate everything that supports them - indeed, I
just now tried it and find
IMO anything that pretends to implement IPv4 but which doesn't do
noncontiguous netasks is simply broken, I don't care whether it
comes from Cisco or Netgear or NetBSD.
For that to work at all across multiple implementations would require
a standard to tell you, when your destination address
Was [running my house LAN with a noncontiguous netmask], for
practical purposes, unsupportable? Was it something likely to cause
subtle bugs all over the networking stack? Was it something
obsoleted more or less 20 years ago? All yes.
Actually, no.
Unsupportable? I don't see anything
The only difference between the two programs is this:
#if 1
read(fd, buf, BUFSIZE);
bmem = (void *)buf;
#else
busmem = mmap(NULL, sb.st_size, PROT_READ, MAP_FILE|MAP_SHARED, fd,
0);
if (busmem == MAP_FAILED)
err(1, mmap);
bmem =
Can't you just version it? Rename existing PT_STEP to PT_OSTEP or
something, define PT_STEP with the new value (instead of introducing
new PT_* name)?
That works for ABI compatability but not API compatability.
/~\ The ASCII Mouse
\ / Ribbon Campaign
X Against
So something naiive like this: [...] will give you the wrong result.
True.
Essentially, you have a shared resource (the fd-number to thing table)
which you are using without any locking. Of course there are races!
Some threading setups allow different threads to have independent file
There are two interesting things here: the timestamps in the file do
not warp backwards by almost two seconds - but they do warp
backwards, by 3353 ns.
Try a different time counter. See kern.timecounter.
kern.timecounter.choice = clockinterrupt(q=0, f=100 Hz) TSC(q=-100,
f=1795636350 Hz)
Actually, my main reason for writing is to mention that I have a
laptop, running 4.0.1, with an re onboard, and have never seen such
random crashes. I can give more details if they matter.
I've got 3 motherboards with re onboard that I've tested, 2 of the 3
have the problem. I checked the
[...]
This is greatly cleaned up in the envsysV2 implementation.
[...]
In envsysV2, a single call is used [...]
Then there's not really anything to discuss, because it's all already
been fixed. Excellent.
/~\ The ASCII Mouse
\ / Ribbon Campaign
X Against HTML
I'm looking for comments about what I call device flavours. [...]
I'm having trouble seeing what this offers over things (like scsibus)
where an abstraction attaches at real hardware and then other things
attach to the abstraction.
flavour acpiib at pci: acpinodebus
filedev/acpi/acpiib.c
is it possible that the re device is writting past its buffer (via
DMA) and overwriting random memory ?
Isn't that one thing the iommu is for? Oh, wait
Well, use machines whose designers cut corners on hardware design and
guess what happens.
Actually, my main reason for writing is to
IIRC, you cannot implement RCU in non GPL software (unless IBM gives
approval for it).
Why not?
Even if it's patented, it's unlikely to be patented anywhere but the
USA (certainly the Wikipedia page gives no reason to think so); there's
no reason the rest of the world should have to suffer the
Having just recently spent quite a bit of time porting a kernel
module from NetBSD-3 to NetBSD-5, and working out a bunch of
synchronization issues, I suggest skipping over NetBSD-4 and going
straight for 5.
Noted, though I doubt a major version jump is in the cards for that
machine in the
[...roll forward pre-MP code to become MP-ready...]
lock(9) outlines locking facilities which I believe I can use to do
[the locking] I want - but there are other issues [...]
You need memory barriers, modern CPUs can do speculative reads, and
some can reorder writes. AFAIK, lock
My assumption is that the big data block written is devided in
several small chunks (disk blocks, 512 bytes), which will then be
written to disk sequentially, and with the system preempting if
there's other work to do. The preemption would further delay the
writes, but write speed not an
Can anyone tell me why, exactly, we shouldn't remove bound AF_LOCAL
sockets from the filesystem on last close?
Well, I wouldn't expect it to be easy; it means that every AF_LOCAL
socket needs to keep track of its directory,name pair. This leaves
open the question of what to do if it has
But I agree that if leaving the sockets around permits no interesting
feature whatsoever (i.e. it doesn't even serve for SO_REUSEADDR),
I've been trying to think of any such feature since this discussion
started. So far i've failed.
it very well could be a design or implementation bug,
I
A reason might be that every other system behaves the same way and
being different will just lead to non-portable code.
Non-portable *how*? What exactly would happen?
I don't know, and if you've got an argument that code written for
either behavior will be ok both places I don't have a
While of course nothing is perfect, I think the number of cases
where you want the routability of IP but have nothing on the local
broadcast domain that can proxy is small enough that the cost of
writing them off outweighs the cost of dealing with the issues that
using IP raises.
Proxies
Most of what I'm writing here has already been brought up elsewhere in
the thread; I'm collecting it here as a response to the specific
questions jgordeev asked. Those who've read the rest of the thread
will probably find nothing new here.
My opinion, which is probably worth approximately what
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 mounting any filesystems, but that's what it
is.
You can't boot
does X have any way to do mouse scaling,
Not very, not core X at least. ChangePointerControl allows defining a
threshold above which pointer motion is accelerated by a specified
rational fraction (or decelerated, I suppose, if a server feels like
implementing fractions 1).
However, that's not
On 2nd thought - how likely are we to ever have real life fonts with
character numbers above 0xff?
Ever's a long time. I don't expect it to be more than another decade
or two before 16-bit characters seem a quaint archaism. (Though
perhaps the we of that question won't be around by then)
Or add a MD function to convert a bus_space_tag_t to a value that can
be printed with (say) %p in MI code that includes most of the useful
info.
I've felt, in recent years, that printf is annoyingly weak in some
respects. For these purposes, it would be really nice to have a format
specifier
Could this be resolved by adding a get label ioctl that could be
used on any device?
That's part of the plan of my devfs.
yuck.
Agreed. For one thing, you can't ioctl anything until you open it,
which is a nontrivial operation for many devices - and closing it when
you're done is a
What's happening is that the signal code (5) is written into p_xstat,
and then the LWP is stopped.
Unfortunately, p_xstat is also used to carry a signal delivered from
GDB to the process (as the fourth argument of ptrace() P_CONTINUE
function).
So what happens, if I correctly interpreted
Let's instead ask us who, and why, some people do drift over to
NetBSD? I would say that a large portion of those are people who
for some reason or other have gotten tired of the magical modules,
autoconfiguration, and magic tools that manage the system for you,
and who wants to have better
[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 preserved.
The files in procfs and kernfs are for the most part
This could also enable you to do
mount -t devfs /etc/devfs-bindchroot.db /var/chroot/bind/dev
for example.
I don't think a static database will cut it. What happens when
someone attaches a new USB stick and devfs generates a bunch of new
nodes? What ownership and permissions should they
I think the pseudo-device abstraction is unnecessary
I think it makes sense, because it allows to limit use of the
interface-attribute-less root to a minimum. There is a reason that
many/most ports use just one mainbus at root.
That doesn't make the pseudo-device abstraction necessary.
have pseudo0 attach at mainbus0 [...]
I did this because I needed a struct device
That's what attach_pseudo does...
I probably could have done it that way, but it looked easier to do it
as a pseudo-bus, and for the purposes at the time, the method didn't
matter all that much.
I think it
(1) dev_t cannot go away, because a fairly fundamental guarantee in
Unix is that two files are the same if stat returns the same (st_dev,
st_ino) pair for each.
This dev_t does not have to correspond, though, to anything else in the
system.
(3) It is also necessary that device nodes continue
/dev has a few reserved directory (like /dev/id). You have no
freedom there. Any access other than that goes to devfsd. It has
knowledge equivalt to sys/arch/*/conf/majors.* as reference. And it
tracks mknod(2), rename(2), etc per-mount point.
When you do mknod(/dev/wd0a);
And now anyone who can jack around with the userspace daemon process
can cause you to mount a filesystem you didn't intend to mount.
Anyone who can meddle with a root-run process can do a lot worse than
that (to start with, mounting that filesystem directly).
/~\ The ASCII
[...]. That makes devfs responsible to resolve confliction, which in
turn leads to some configuration thing, which I definitely want to
avoid.
You need some kind of persistent state *somewhere*, to support chmod,
chown, mv, rm, etc. Or are you proposing to break those? That idea
strikes me
Lack of chmod/chown/etc in /dev would be a total showstopper (for
me, at the very least) for production use.
Could you tell me the senario how it sucks?
[...example, plain user access to serial line...]
That's one of the scenarios I've run into, though for me it's at least
as often been
Linux had a devfs and [dropped] it. Now it has udevd(8). Most
likely the penguins had a reason for this.
Surely there are mailing list messages or something that outline that
reason? (Not that I have any idea where they'd be, but don't we have
at least a few people with feet in both camps?)
I have a question reguarding mmap(2)ed files which are modified.
Modified through the mmapped memory, I take it you mean? (They can
also be modified through the filesystem interface, and most of the
interesting questions hinge on having two different access paths to a
single set of bytes.)
I have seen NFS fail (with the old 8K packets) on a network that was
badly terminated (back in the 10base2 days) because the back-to-back
packets self-collided while single packets with some spacing made it
fine.
I recall I once had an NFS problem that exhibited itself as failures
reading
This can easily happen if you copy the image between disks with
different block sizes.
Now _there_ is a valid argument for doing everything in terms of bytes
(as was discussed briefly upthread).
/~\ The ASCII Mouse
\ / Ribbon Campaign
X Against HTML
fs_fsbtodb depends on the block size of the underlying medium.
Does it? All you need to do is make a mental switch from thinking of
fs_fsbtodb as filesystem blocks to underlying device blocks to
thinking of it as filesystem blocks to interchange blocks, where an
interchange block is defined as
To support 512bytes/sector devices, we may have two choice: [...]
What about 512? They exist; I have a floppy drive which I've been
carefully hoarding because it has 256-octet blocks, the only device
with 512-octet blocks I've ever seen (and it's SCSI, the only SCSI
floppy drive I've ever seen,
time cat /usr/pkg/lib/python2.5/test/audiotest.au /dev/audio
=
[ silence ]
real0m2.912s
How large is that file? In particular, if it's not pretty close to
23296 (2.912*8000) bytes, something is wrong.
dmesg | egrep -i 'sound|audio'
=
[ nothing ]
Assuming that dmesg by itself
98 matches
Mail list logo
