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:
>
>:
>
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
considerably less than a
millisecond wide.
Doing that from software practically rules out any high-level.
You might consider putting a PIC out there for the actual timing,
and having a control interface to it along the lines of "pulse this
line move ignition earlier, pulse that one and mov
ere is some kind of glitch somewhere when the TSC
>take over as timecounter?
Unlikely.
--
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
top all PHY drivers from calling MEDIAINIT, and
>call it once per miibus instance in miibus_attach() or miibus_probe()
>instead?
I just had reason to mess around with a PHY GigE related problem
as well, and I can only say that the MII code might have sounded
like a good idea at the time bu
Eventually vinum will either be absorbed into
GEOM as one class or (better) be implemented with a set of simple
classes in GEOM.
--
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
In message <[EMAIL PROTECTED]>, Miguel Mendez writes:
>Well, if you've used recent versions of the veritas volume manager
>fronted you'll notice that they give the cli command output in a window,
>that's what I intend to do.
They did that in 1994...
--
Poul-H
a program to list all the slices and partitions, because
>I couldn't find one already in existance. fdisk and disklabel only seem
>to work on one disk at a time, and I wanted to see everything.
Yes :-)
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP s
involved that made the combination difficult. Perhaps
in the future).
--
Jaye Mathisen, COE Systems Manager(406) 994-4780
410 Roberts Hall,Dept. of Computer Science
Montana State University,Bozeman MT 59717 [EMAIL PROTECTED]
-
, D. M. Ritchie.
>
>They hacked the compiler to hack the passwd program when it was
>being compiled, and also to hack the compiler to include hacks
>to the compiler and the passwd program when the compiler itself
>was being compiled.
Sigh.
Wrong reference.
That was from Bri
In message <[EMAIL PROTECTED]>, David Schultz writes:
>Thus spake Poul-Henning Kamp <[EMAIL PROTECTED]>:
>> That was from Brians ACM Turning award thankyou-presentation.
>
>http://www.acm.org/classics/sep95/
Ahh, at least I got one more parameter right than Terry
of
>these features are extras, not the basics, correct? Other than SMP, of
>course.
It is the intent that GEOM will be standard (or basics if you like).
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer |
In message <[EMAIL PROTECTED]>, j mckitrick writes:
>On Fri, Jun 07, 2002 at 02:44:27PM +0200, Poul-Henning Kamp wrote:
>| In message <[EMAIL PROTECTED]>, j mckitrick writes:
>| >| On the other hand, there are numerous new features (GEOM, TrustedBSD,
>| >| OpenPA
2f,0,0) at syscall+0x1db
>syscall_with_err_pushed() at syscall_with_err_pushed+0x1b
>--- syscall (190, FreeBSD ELF, lstat), eip = 0x280b2f33, esp = 0xbfbff1ec, ebp -
>
>To Unsubscribe: send mail to [EMAIL PROTECTED]
>with "unsubscribe freebsd-hackers" in the body of t
I have a bunch of 8" floppies I need to try to recover contents
from, is there anybody out there who has a 8" drive they'd be willing
to part with for $$ ?
If it comes with the magic SA800-PC cable it would be just perfect.
Poul-Henning
--
Poul-Henning Kamp | UNIX since
In message <[EMAIL PROTECTED]>, Hellmuth Michaelis writes:
>Poul-Henning Kamp wrote:
>
>> I have a bunch of 8" floppies I need to try to recover contents
>> from, is there anybody out there who has a 8" drive they'd be willing
>> to part with for $$ ?
is an I belive it is actually the case on both
-current and -releng4 that disabling newreno improves TCP performance.
I belive running an X11 application or scp(1) over a wavelan is a very
good test-bed for this issue.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED]
In message <[EMAIL PROTECTED]>, Michael Sierchio writes:
>Poul-Henning Kamp wrote:
>
>> Yes, I can attest to this an I belive it is actually the case on both
>> -current and -releng4 that disabling newreno improves TCP performance.
>>
>> I belive running
nsubscribe: send mail to [EMAIL PROTECTED]
>with "unsubscribe freebsd-hackers" in the body of the message
>
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribut
",
>so after it finds the string it goes back to the first newline
>and returns the offset of the character after that. :(
Luigi, get in touch with W Gerald Hicks <[EMAIL PROTECTED]>,
he has patches which does this by objcopy'ing the binary file to
an elf-object and then lin
computers I run, and I need a
>reliable way to get passage of time (I don't need date/time, just
>the passage of it) for different internal operations in the program.
Use UTC time, it has no daylight savings problems.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTE
In message <[EMAIL PROTECTED]>, "M. Warner Losh" writes:
>In message: <[EMAIL PROTECTED]>
> Poul-Henning Kamp <[EMAIL PROTECTED]> writes:
>: In message <005f01c22dd1$7be7d180$0300a8c0@fivehundred>, "Andrei Cojocaru" writ
>: es:
&
I think it is far too early
for an MFC. Suggest you provide a -stable friendly patchfile
until we have this issue settled in -current.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never
they only available to the kernel. If so, how can I get a reasonable
>timer figure from user space?
There is no problem in making them available to userland, only the
question of which .h file to put them in and how to avoid breaking
some standard or other doing so.
--
Poul-Henning Kamp
k the forum would be interested as well.
I have yet to see a PC104 card which didn't support FreeBSD or (MSDOS 3.11
for that matter).
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
I've started to type in my mental sticky notes, have at it:
http://people.freebsd.org/~phk/TODO/
--
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 wha
In message <[EMAIL PROTECTED]>, Maxim Sobolev writes:
>Poul-Henning Kamp wrote:
>>
>> I've started to type in my mental sticky notes, have at it:
>>
>> http://people.freebsd.org/~phk/TODO/
>
>Could you please modify reference to each of the t
D turned down because it was a pile of shit, and now you're
out to get revenge at the people who called you on your fraudlent
claims and made your the laughingstock of your equally loosing
#l33td00ds peers.
Here's a dime, get yourself a real OS.
You'd better tell your mom you've
t
correctly uses N/2^64 fractional the way binary computers prefer 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
d bintime, except that it
>:correctly uses N/2^64 fractional the way binary computers prefer it.
>:
>:--
>:Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
>
>Hmm. That's certainly a reasonable point. I suppose a negative
>representation is still possible
bits in the kernel,
rather than have to s/time_t/time64_t throughout the kernel.
--
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
In message <[EMAIL PROTECTED]>, "M. Warner Losh" writes:
>In message: <[EMAIL PROTECTED]>
>I think that this is a worthy problem to solve. But not for 5.0. [...]
Good thinking.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] |
t scan the CIS tuples for me and perform the appropriate allocations?
>If so, how do I get at the resource?
>If not, how would I go about doing this myself in the driver?
>And what would I want to put in my driver's xxx_probe() routine?
Suggest you look at the sys/dev/sio/sio_pccard
In message <[EMAIL PROTECTED]>, Bruce M Simpson writes:
>On Thu, Sep 05, 2002 at 09:22:11PM +0200, Poul-Henning Kamp wrote:
>> Suggest you look at the sys/dev/sio/sio_pccard.c file...
>
>I forgot to mention I'm working on -STABLE. =o)
"Don't", that'
In message <[EMAIL PROTECTED]>, Seva Tonkonoh writ
es:
>Hi,
>
>I have recently come across an old little discussion about InterMezzo.
>I 've got the impression that it wasn't really welcome to FreeBSD.
What is it ?
--
Poul-Henning Kamp | UNIX since Zilo
nt over the weekend.
>
>I'm very interested in comments and testing on -stable to help update the
>general architecture and stability.
IP-over-SCSI ?
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer
In message <[EMAIL PROTECTED]>, Ju
lian Elischer writes:
>
>
>On Sat, 7 Sep 2002, Poul-Henning Kamp wrote:
>>
>> IP-over-SCSI ?
>>
>
>Well I've just been reading about SCSI over IP so
That's different. IP-over-SCSI is a much wante
In message <[EMAIL PROTECTED]>, Nate Lawson wri
tes:
>On Sat, 7 Sep 2002, Poul-Henning Kamp wrote:
>> In message <[EMAIL PROTECTED]>, Ju
>> lian Elischer writes:
>> >
>> >
>> >On Sat, 7 Sep 2002, Poul-Henning Kamp wrote:
>> >>
In message <[EMAIL PROTECTED]>, Bruce M Simpson writes:
>What I'd like to do is modify a Soekris net4501 for this.
There is a hardware watchdog in the Elan CPU used in the Soekris,
I plan to add support for it to the elan-mmcr driver when I get
a timeslot for it.
--
Pou
es or no? What is the desired behaviour?
No.
>The fact that this did work, was it a bug or did this come out due to some
>other change. The stacktrace from read(2) is below.
This hasn't worked for a long time in -current.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTE
In message <[EMAIL PROTECTED]>, Mark Santcroos writes:
>On Wed, Sep 25, 2002 at 07:41:44PM +0200, Poul-Henning Kamp wrote:
>> >The fact that this did work, was it a bug or did this come out due to some
>> >other change. The stacktrace from read(2) is below.
>>
crypt. The
>> logical choice is the device.
>
>Have you seen ports/security/vncrypt?
Or src/sys/geom/geom_aes ?
I have what I hope is industry-strenght encryption in my development
tree with only a few more issues to straigten out before it hits -current.
--
Poul-Henning Kamp
In message <[EMAIL PROTECTED]>, "Daniel O'Connor"
writes:
>On Thu, 2002-09-26 at 14:18, Poul-Henning Kamp wrote:
>> >Have you seen ports/security/vncrypt?
>>
>> Or src/sys/geom/geom_aes ?
>
>Whoo :)
>
>> I have what I hope is indust
le bit.
Geom will deal with all I/O requests as 64 bit byte offsets, so as such
GEOM will solve the problem, and provided the disk-driver authors
follow suit, this entire thing can be fixed before 5.0.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TC
;did't respond for unknown reason (busy?).
Hey easy now :-)
I'm discussing the issue with core@ right now, and if they agree
that this should go in the tree, I'll be your designated committer
for the first period of time.
Stay tuned, I'll get back to you when core@ gives me
n an
architecturally sane manner.
So they were removed, and good riddance.
If a buffered access-mode on block devices is desired, it should
be implemented either as an ioctl controllable feature, or as
a GEOM module. The latter is probably by far the easiest way.
--
Poul-Henning K
ired, and was sort of promised.
And we're close to the point where it can happen...
--
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 adequatel
27;t do it).
Man 4 geom is a good place to start.
There will also be a tutorial friday afternoon about GEOM
at BSDCONeuro2002 in amsterdam next month.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-t
In message <[EMAIL PROTECTED]>, Bakul Shah writes:
>Oh well.
>I am not going to argue about this over and over and over
>again.
Thankyou, a very wise decision sir!
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
Fr
In message <[EMAIL PROTECTED]>, n0go013 writes
:
>On 04.10-18:27, Poul-Henning Kamp wrote:
>> In message n0go013 writes :
>> >On 04.10-15:40, fergus wrote:
>> > > On 04.10-14:20, Poul-Henning Kamp wrote:
>> > > [...]
>> > > > I
In message <[EMAIL PROTECTED]>, Lars Eggert writes:
>This is a cryptographically signed message in MIME format.
>
>--ms040706010906030302070807
>Content-Type: text/plain; charset=us-ascii; format=flowed
>Content-Transfer-Encoding: 7bit
>
>Poul-Henning Kamp
In message <[EMAIL PROTECTED]>, Ju
lian Elischer writes:
>No, it is established principal tha the importer of new features has the
>responsibility to make older subsystems work.
I'm _so_ glad to hear _you_ say that:
When will you have made KSE work on sparc64 and ia64 ?
--
In message <[EMAIL PROTECTED]>, Daniel E
ischen writes:
>On Fri, 4 Oct 2002, Poul-Henning Kamp wrote:
>
>> In message <[EMAIL PROTECTED]>, Ju
>> lian Elischer writes:
>>
>> >No, it is established principal tha the importer of new features has the
>
In message <[EMAIL PROTECTED]>, Bruce Evans writes:
>On Sat, 5 Oct 2002, Peter Wemm wrote:
>
>> Bruce Evans wrote:
>> > On Fri, 4 Oct 2002, Poul-Henning Kamp wrote:
>> >
>> > > Worst case you will have the option to use:
>> > >
>
501 - 600 of 654 matches
Mail list logo
