terms of character devices now? Looks like all the
>support for block devices is contained in the cdevsw struct.
quick answer: yes.
:-)
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
I understand your question here...
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
To Unsubscribe: send mail to [EMAIL PROTE
I'm interested is it would make a full nvidia driver
>port quite a bit easier.
Sorry, I know of no current plans which adress this.
The issue is non-trivial to fix because we currently don't pass
dup(2) events through the vnode layer.
--
Poul-Henning Kamp | UNIX since Zilog Zeus
In message <[EMAIL PROTECTED]>, Terry Lambert writes:
>Poul-Henning Kamp wrote:
>> >> Most likely he means a per-open(2) opaque datum that is kept in
>> >> struct file and passed to the underlying routines.
>> >
>> >Sorry, unbelievably bad at e
In message <[EMAIL PROTECTED]>, Dav
e Rufino writes:
>
>
>On Sat, 8 Dec 2001, Poul-Henning Kamp wrote:
>
>> >They are talking about "per-open", not "per-fd-instance" data,
>> >which could easily exclude dup, dup2, and fcntl(f_DUPFD).
>
r way.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "u
e it possible to define a new mode from userland with an ioctl.
(hint: instead of the index, put a pointer to the struct fd_type into
the fd_data structure.)
Preferably, send one patch per step rather than one huge patch since that
will make reviewing easier.
First volounteer to send me e
In message <[EMAIL PROTECTED]>, "And
rew R. Reiter" writes:
>
>Someone already doing this? If not, I'm down.
You won, you're the first one in my inbox :-)
Ready ?
Steady ?
Start!
:-)
>
>On Tue, 11 Dec 2001, Poul-Henning Kamp wrote:
>
>:
>
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe
I raised the issue on [EMAIL PROTECTED]
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
To Unsubscribe: send mail to [EMA
t cdevsw sio_cdevsw = {
.d_maj = MAJOR_AUTO,
.d_flags = D_TTY,
.d_open = sioopen
etc
etc
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never
eed
>> to modify in order to make sure that my new header files
>> get installed properly when I do a make installworld?
>
>None.
... which is a bug.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer
.x but we would have multiple respiratory
failures in the re@ team if I even think about it until the RELENG_5
branch has been laid down, so for now you're on your own.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer
are other reasons why you would generally not want
to spend too much time in the timeout function, mostly that it may
screw up other time-critical things in the system.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer | BS
have then run sequentially
from a single thread, possibly via a task-queue.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
the stuff on top of it.
But to add to my knowledge-base: What length of delays are you
looking for ?
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what ca
*/
+ {T_DIRECT, SIP_MEDIA_REMOVABLE, "General Flash Disk Drive",
+"*", "*"},
+ /*quirks*/ DA_Q_NO_6_BYTE|DA_Q_NO_SYNC_CACHE
}
};
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP si
),
rev 2.05
I do find it odd, that the quirks are not assigned in the umass code and
passed to scsi_da some way, that would be much more reliable.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-
In message <[EMAIL PROTECTED]>, Bernd Walter writes:
>On Thu, Jun 05, 2003 at 04:10:59PM +0200, Poul-Henning Kamp wrote:
>> In message <[EMAIL PROTECTED]>, Bernd Walter writes:
>>
>> >Mine works fine without quirks:
>> > port 3 addr 3: full speed
At least originally imgact_gzip.c was heavily a.out aware.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be expl
f
>
>The patch should apply cleanly on any recent -CURRENT. Sorry, it won't
>work on 5.0-R
>It's my first patch against the kernel code, so expect a few
>non-BDE-complying mistakes. Sorry
>for that.
>
>Thanks,
> Jason
>--
> Jason Stryker
> [EMAIL
you.
Anyway: now please run along, be quiet and find something to play
with, and leave the grown ups around here to do their work.
Poul-Henning
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
r even that you have
code in the tree: Yeah, right, and sell me the Eifel tower too.
There is one count where I will concede that the FreeBSD project
sucks: We have really lousy incompetent stupid boring trolls.
Poul-Henning
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTE
project by lamely trolling our mailing lists.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by i
ropriate
>ioctl for device" unless you call it on an individual partition
>(/dev/ad0s1a for example).
>
>Is there a way around this?
Use the ioctls you find in they should work on all
disk devices.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED]
ere was enough trouble in
>the 70s.
Peter Salus book "A Quarter Century of UNIX" mentioned that he got
in trouble and that AT&T stopped the distribution (to the extent
that they could).
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP si
blem for our NCryptfs. To provide a
>comprehensive solution, we have to also handle swap. Luckily in Linux,
>there are specific VOPs and APIs that make it easy to hook a crypto f/s w/
>the swap.
I will present a paper on the GBDE encrypted disk facility at BSDcon2003.
--
Poul-Henning Kam
om disk) on the
5.x system, boot that kernel using the mfsroot as root filesystem
and try to do the surgery from there.
The advantage to this approach is that you can explore the issues
returning to your 5.x installation and adjust your approach.
--
Poul-Henning Kamp | UNIX since
rg().
>
>I just found a large number of calls in the ATM code that have just
>M_ZERO or even 0 flags.
>
>Anything against this check?
Good point, please implement!
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer
gument "struct bio* bp"
>Now I need to get to the "struct *buf" that bp
>belongs to.
You can't do that, there may not be any struct buf.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer
an easy to use tool to point people at when they
run benchmarks.
Source: http://phk.freebsd.dk/patch/ministat
Poul-Henning
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attrib
ll be called GEOM Gate.
>This software provide disk devices mounting through the network.
COOL
> http://garage.freebsd.pl/geom_gate.tbz
I'll look over it when I have a second.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC
through it's children so there shouldn't be a problem.
>Then the ELAN specific devices (like GPIO and flash) can attach to 'mmcr'.
>
>This seems straight forward. Maybe I'm missing something. 8-)
That's my take too. And MMCR belongs on nexus not on legacy fro
the current code path there is a handle for
>nexus or any other device_t.
In fact what you may want to do is hang the entire MMCR off the nexus
as a bus, and hang the various drivers off that bus.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP
presents a disk I/O request.
For historical reasons, a buf contains a bio, but that is by
no means the only way to create a bio.
Throughout geom bio's are created a destroyed which have no
relation to any specific buf, for instance to read the key
sectors in gbde.
--
Poul-Henning Kamp
In message <[EMAIL PROTECTED]>, Bernd Walter writes:
>On Wed, Aug 06, 2003 at 12:18:28PM +0200, Poul-Henning Kamp wrote:
>> In message <[EMAIL PROTECTED]>, Bernd Walter writes:
>> >I need to add I2C support for a Elan520 based soekris system.
>> >The system
In message <[EMAIL PROTECTED]>, Bernd Walter writes:
>On Wed, Aug 06, 2003 at 12:45:43PM +0200, Poul-Henning Kamp wrote:
>> In message <[EMAIL PROTECTED]>, Bernd Walter writes:
>> >On Wed, Aug 06, 2003 at 12:18:28PM +0200, Poul-Henning Kamp wrote:
>> >> In
In message <[EMAIL PROTECTED]>, Peter Jeremy wri
tes:
>[Redirected to -hackers because this isn't directly relevant to the
> actual code committed]
>
>On Fri, Aug 15, 2003 at 05:04:02AM -0700, Poul-Henning Kamp wrote:
>> Suggested replacement command sequence on the c
e to test
Please use /usr/src/tools/tools/ministat to do a proper statistical
benchmark.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be exp
ze performance.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
___
[EMA
I need two to sustain the IO
>required?
Spreading it will give you more I/O bandwidth.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what c
3 of these
>shelves what would my expected loss of IO be?
The loss will mostly be from latency, but how much is impossible to
tell I think.
The statistics of this, even with my trusty old Erlang table would
still be too uncertain to be of any value.
--
Poul-Henning Kamp | UNIX since Zilo
d 5-20T filesystem and actually fsck them.
I am not sure I would advocate 64k blocks yet.
I tend to stick with 32k block, 4k fragment myself.
This is a problem which is in the cross-hairs for 6.x
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP sin
more inodes than I need, it also saves fsck time.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by
n that large disks will contain large files.
>
>It strikes me that driving the block size up (as far as 1M) and having
>a 256 (or so) fragments might become appropriate.
Sounds like a _great_ project for somebody :-)
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED
is more or less all the
places in the kernel which uses makedev().
As you may have noticed I've started evicting these from the
console related code.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-
on didn't warn you about this.
I have just fixed that.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can a
and maybe we can find
a better way to do that ?
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
ff for jails: much.
:-)
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
__
/dev/io:
#include
#include
#include
#include
#include
int
main(int argc, char **argv)
{
FILE *f;
f = fopen("/dev/io", "r");
outl(0xe11c, 0x120);
outl(0xe124, 0xd0602004);
outl(0xe134, 0x18600020);
outl(0xe11c, 0x130);
[
le (or was it CPIO?)
records which I then sent through tcp to the remote machine.
I don't have the code anymore, but the idea is available to anyone
who wants it :-)
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer
what project members do in
their own projects is of course a different matter).
I, and I think other members of FreeBSD, would appreciate it if
the members of DragonflyBSD would adhere to this peace-keeping
rule as well.
Poul-Henning
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL P
Sorry, I'm reducing my email load by dropping off [EMAIL PROTECTED]
If you want my attention on a problem, send me private email, Cc' me
or send it to another list were I'm subscribed.
Sorry...
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED]
In message <[EMAIL PROTECTED]>, Warner Losh writes:
>In message <[EMAIL PROTECTED]> Poul-Henning Kamp writes:
>: 6. Add the "rx50" entry from above to the table to show how simple
>: that is now.
>
>But rx50 also needs some extra processing to handle the
Can you provide some sample parameters please ?
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
To Unsubscribe: send ma
suggests.
>
>It would be very useful, IMO, to have a simple URL like this to access the
>PR database.
>
>Opinions ?
Great idea...
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-taho
MAKEDEV script.
/dev/MAKEDEV should have lived in /etc from the
beginning anyway...
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained
-int.c
>g++ Graph.cpp mt19937b-int.o
>./a.out
>
>Known to compile okay with GCC 3.0.3 and 3.1
>
>
>
>To Unsubscribe: send mail to [EMAIL PROTECTED]
>with "unsubscribe freebsd-hackers" in the body of the message
>
--
Poul-Henning Kamp | UNIX since Zilog
a cluster of machines to test it: Using jail(8) you
can run a PVM cluster of any size on one machine.
Any takers ?
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what
In message <[EMAIL PROTECTED]>, Brooks Davis writes:
>On Mon, Jan 21, 2002 at 12:32:04PM +0100, Poul-Henning Kamp wrote:
>> /usr/bin/make already have hooks for remote execution of jobs when
>> running parallel. All that is missing before we can do distributed
>> p
em to envoke a set of jobs which is a fairly straight
>forward thing to do (it's not much harder then envoking rsh and you
>could easily write a simple wrapper that provided rsh symantics if it
>doesn't exist already.)
Uhm, PVM is a *much* faster way to start a job than rsh...
] In-Reply-To: Your message of "Mon, 21 Jan 2002 09:09:54 PST."
] <[EMAIL PROTECTED]>
] Date: Mon, 21 Jan 2002 21:33:04 +0100
] Message-ID: <[EMAIL PROTECTED]>
] From: Poul-Henning Kamp <[EMAIL PROTECTED]>
]
] In message <[EMAIL PROTECTED]>
diman <[EMAIL PROTECTED]> wrote:
>>
>>
>> I found it interesting. I have 3 idle boxes out here and
>> friend of mine has ~20, and parallel make is a dream.
>> Don't know about someone else, I'm giving your proposal
>> a try.. :-)
>>
>>
Did you make any progress on this Andrew ?
In message <[EMAIL PROTECTED]>, Poul-Henning Kamp writes:
>In message <[EMAIL PROTECTED]>, "And
>rew R. Reiter" writes:
>>
>>Someone already doing this? If not, I'm down.
>
>You won, you're the f
saturating the bus with 5400RPM drives...
You can (over-)saturate a 32bit/33MHz pci bus with two or three
modern ATA disks.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to mali
#x27;s on...
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
To Unsubscribe: send mail to [EMAIL PROTECTED]
wit
#x27;legal', but it doesn't give explicit
>release of said source code.
Well, I have never heard claims that BSD was tainted by any USL
release besides 32V, so this is good enough for me to put my 1.X
tree up without fearing ugly lawyers.
Now, where did all those CD's go...
--
1.X tree
>> up without fearing ugly lawyers.
>
>Ahh, the advantages of being overseas, away from litigious lawyers. :)
No not really, I just can't imagine who would be paying the laywers
now that Caldera has marched their standard on the OSS side.
--
Poul-Henning Kamp | U
t tree now,
CVS is probably not up to it, but perforce might be.
now _THAT_ would be usable history online... :-)
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to mali
at most problems
come from the i8254 timecounter.
I made a commit recently which made the core-code more robust to
bad interrupt jitter/latency, basically it would return timestamps
with too many microseconds or nanoseconds because it only tried to
roll over to seconds ones. Now it while()'s
In message <[EMAIL PROTECTED]>, "M. Warner Losh" writes:
>In message: <[EMAIL PROTECTED]>
> Poul-Henning Kamp <[EMAIL PROTECTED]> writes:
>: But the i8254 is a piece of shit in this context, and due to
>: circumstances (apm being enabled0 mo
where I'm doing my experiments.
Try swapping so you use the RTC for hardclock & statclock.
Let the i8254 run with 65536 divisor and do only timecounter service.
That would be a very interresting experiment.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | T
In message <[EMAIL PROTECTED]>, John Polstra writes:
>Agreed. But in the cases I'm worrying about right now, the
>timecounter is the TSC.
Now, *that* is very interesting, how reproducible is it ?
Can you try to MFC rev 1.111 and see if that changes anything ?
--
In message <[EMAIL PROTECTED]>, John Polstra writes:
>In article <[EMAIL PROTECTED]>,
>Poul-Henning Kamp <[EMAIL PROTECTED]> wrote:
>> In message <[EMAIL PROTECTED]>, John Polstra writes:
>>
>> Can you try to MFC rev 1.111 and see if that chan
In message <[EMAIL PROTECTED]>, John Polstra writes:
>In article <[EMAIL PROTECTED]>,
>John Polstra <[EMAIL PROTECTED]> wrote:
>> In article <[EMAIL PROTECTED]>,
>> Poul-Henning Kamp <[EMAIL PROTECTED]> wrote:
>> > In message <[EMAIL
ap,
ie: if you can have something like:
call microuptime()
tc = timecounter;
(interrupt and do other stuff for several seconds)
... overflow in arithmetic
But you would have to pummel your kernel pretty bad for that. On the
other h
arithmetic overflow because the call to microuptime() gets
>> interrupted for too long.
>
>'Interrupted for too long'. Do you mean 'not interrupted enough', aka
>a long interrupt blockage? (I'm trying to understand here.)
See my previous e
In message <[EMAIL PROTECTED]>, John Polstra writes:
>In article <[EMAIL PROTECTED]>,
>Poul-Henning Kamp <[EMAIL PROTECTED]> wrote:
>> In message <[EMAIL PROTECTED]>, John Polstra writes:
>> >In article <[EMAIL PROTECTED]>,
>> &
e calculate from is not valid for the delta we get from the hardware.
I'm not sure this answers your question, if not it is not bad will, just
me not understanding the question :-)
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
Fre
In message <[EMAIL PROTECTED]>, John Polstra writes:
>In article <[EMAIL PROTECTED]>,
>Poul-Henning Kamp <[EMAIL PROTECTED]> wrote:
>> In message <[EMAIL PROTECTED]>, John Polstra writes:
>> >Yes, I think you're onto something now. It's a
inter to
be volatile because it obviously isn't. Do I really need to cast it ?
tc = (struct timecounter *)timecounter;
That looks silly to me...
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer | BSD
g my netgraph module under -current yet.
Well, either way I will commit the volatile and this NTIMECOUNTER to
-current now, it's certainly better than what is there now.
Thanks for the help, I owe you one at BSDcon!
Poul-Henning
Ohh, and btw: do I need to say that I'm dying to know wh
Thanks.
Yes, but not using the vndriver.
There is DARPA sponsored work going on to do this "right". For an old
overview of the concept:
http://freefall.freebsd.org/~phk/Geom
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 95
ing it so I nuked it...
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with
printf("Adjusting mask to %08x\n", mask);
mask <<= 1;
}
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what
;last call", if the drivers are not fixed by may 1st
the HARP ATM stack will be put in the attic.
If anybody is interested in actively maintaining this code, I may be
able to find a donor for some ATM cards.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TC
mething), onemore)
!= 0) {
chugchugchug(argthisa;
}
for instance.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can ad
In message <[EMAIL PROTECTED]>, "Mike Meyer" writes:
>Poul-Henning Kamp <[EMAIL PROTECTED]> types:
>> In message <[EMAIL PROTECTED]>, "Mike Meyer" writes:
>> >David O'Brien <[EMAIL PROTECTED]> types:
>> >> On We
In message <[EMAIL PROTECTED]>, "Mike Meyer" writes:
>Poul-Henning Kamp <[EMAIL PROTECTED]> types:
>> In message <[EMAIL PROTECTED]>, "Mike Meyer" writes:
>> I'm advocating that the rule focus on readability rather than trying
>> t
NULL)
or
if (foo != NULL)
2. In conditions, non-interger numeric types should be explicitly compared
to zero
if (float_t == 0.0)
3. Integers need not be explicitly compared to zero:
if (foo & MASK)
not
if ((foo & MASK) != 0)
--
Poul-Henning Kamp
Or am I missing something here?
Right, and since the integer is well defined,
if (!strcmp(a, b))
is perfectly understandable so what is the problem ?
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer | BSD si
quot;. When read "if not string compare a with b then do X",
>is the opposite of the the logic of the expression does. Which is
>"if string compare a with b is equal then do X". ["if (strcmp(a,b) == 0)"]
Well, we're clearly into "IMO" land here, so
h
>
> if (!strcmp())
>
>Which one is right? The first one should mean "are the same" but
>really means "are different" and likewise for the second one.
Guys, strcmp() has been defined that way for almost 30 years, get
used to it, and don't demand o
ash(8), anyway.
>
>If nobody objects, I'd like to move the relevant stuff out of the
>dumpon(8) manual and proceed to remove the program itself as described
>above.
>
>Thanks.
>
>To Unsubscribe: send mail to [EMAIL PROTECTED]
>with "unsubscribe freebsd-hackers&q
a divert ipfw rule for incoming trafic from the
attackers IP# to capture all the tricks he is trying to
do.
Log the received packets in detail in pcap format files.
Report the packets to Dshield.org
etc.
Any takers ?
--
Poul-Henning Kamp | UNIX since
ht now that inp_lport in the pcb is getting set during the
>first system call, and causing the subsequent ones to fail. I don't have
>all the answers though, and I need to get some sleep... Hoping someone
>who understands the pcb functions can point out exactly what the error is
>in here
n't forget to say so to people
who might, directly or indirectly, provide feedback to DARPA.
I hope this answers the FAQ on UFS2, GEOM and all that.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer | BSD since
some time.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsu
pletely different than what's
>been done on AIX, Solaris and Unixware.
We are working very hard to make procfs optional in FreeBSD for a
number of reasons.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer | BSD
ched, there is no filesystems
mounted yet.
Best suggestion is to use an ioctl to download the data from
userland.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what
401 - 500 of 654 matches
Mail list logo
