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]
n see a
GEOM_RAIDFRAME (I gather Pawel is trying to help Scott on this).
Maybe we will also see a GEOM_VINUM class and who knows what else.
And maybe some day down the road, somebody will pick up on the
consolidation idea, or maybe he will instead show it to be hopelessly
idealistic and burri
0,$0xfff0# reboot the machine
> >
> > which indeed works! (OpenBSD, for example, uses ljmp $0xf000,$0xfff0).
committed to FreeBSD -current.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer | B
1. Look for BIO_DELETE in the kernel.
2. Use GBDE or other encryption.
3. Stop bikeshed now, 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
system as one
>of the attack scenarios to protect against ?
>(Not meaning, that secure erase would really solve
>that problem ...)
See my paper for a suggestion about using weak-link/strong-link
methods for that.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED]
en proven again and again that you cannot reliably overwrite
data on a magnetic media. In particular the difference in read/write
geometry and lack of fine control over head placement makes this
impossible.
The only reliable way to loose data is to encrypt them and throw the
key away.
Live with i
itself off, after which a breach of the strong
link is no longer a risk to the data.
Now *that* is a DIY project for the dedicated hobbyist :-)
The terminology and principle, is from atomic weapons which have a
similar security profile:
http://nuclearweaponarchive.org/Usa/Weapons/Pal.html
enjoy
-
In message <[EMAIL PROTECTED]>, Wilko Bulte writes:
>On Fri, Nov 28, 2003 at 12:43:30PM +0100, Poul-Henning Kamp wrote:
>> I have already described one solution to this in my GBDE paper at
>> BSDcon.
>
>...
>
>> Now *that* is a DIY project for the dedicated hob
e,
>but if I got it right, do you (Greg) agree to remove it from -current?
My proposal is to do just that with both vinum and raidframe until
one or possibly both are up to full strength again.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP sin
eat
anyway.
I'd say lets kick them both into perforce and let whoever wants
their hands have a go at them.
Poul-Henning
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer | BSD since 4
le? Do you want to say something? Something like "If phk
>and grog agree, it must be right"? :-)
A lot of people out there will start looking out for black helicopters
if they see the two of us agree, so I would like to state for the
record that while you words _seem_ to say the same
training camp in p4.
--
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.
_
eling format because bsdlabel has
a number of problems going forward.
GPT is our current candidate.
--
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 adeq
x27;s a significant risk that
5.3 and all future releases will ship with partially broken RAID
support. I'm pretty certain we don't want that either.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer | BSD si
give an idea about the relative urgency, we are probably talking
february or march this year.
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 att
debugging/coding, learn to code if need be,
donate money so somebody else can code if you can't do anything
else.
--
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
side of vinum to publish "providers" and service
I/O requests on those instead of the current cdevsw.
Don't be mislead by these four easy steps, there is a lot of stuff to
do in vinum to get these done, a lot of then undoing things as Greg
has already remarked, but if you do it in
with the SMPng work,
even if that means breaking vinum further until Gregs team catches
up.
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
ng is to get the people interested
on this collected on a mail-alias, and for them to discuss how the
can work together to make something happen. After that, try to define
"something" closer.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP s
Hi Allan,
Can you please redo the diff -with '-u' ?
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 attribute to malice what can adequately be ex
you want.
--
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.
___
[EMAIL
green - never executed with giant.
Brownie points: Get slashdotted when they discover you did 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 adequa
In message <[EMAIL PROTECTED]>, "Wm. Da
ryl Hawkins" writes:
>
>I've written a driver for the Intel i8xx TCO watchdog timer for
>both FreeBSD-CURRENT and FreeBSD-STABLE.
Is this written against the API in -current ?
--
Poul-Henning Kamp | UNIX since Zi
http://people.freebsd.org/~phk/funding.html
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 attribute to malice what can adequately be explained by incompetence
In message <[EMAIL PROTECTED]>, Dan Langille writes:
>On Thu, 8 Apr 2004, Poul-Henning Kamp wrote:
>
>>
>> http://people.freebsd.org/~phk/funding.html
>
>typo :(An before any of you get an
>
>Should be "And", not An.
Fixed, thanks!
--
Poul-Henning
such precense.
I realize that marketing budgets might become available if I could
offer better PR for donations, but it is really outside my power
to do so.
Does that answer your questions ?
Poul-Henning
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP
w hard it would be to enforce source-IP
compliance with the jail restriction ?
--
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 inco
e. I.E.
>
> traceroute -s
>
>Otherwise it might fail.
How does traceroute and ping normally determine which source address
to use ? Can't we use that mechanism to default them to the right thing ?
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED]
GEOM friendly:
[...]
--
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 incompet
(data here)
> void *moredata;
> size_t morelen;
>};
>
>What is the proper way of sysctl'ing IN the data from moredata?
>
>I need to make a copy of the sysctl req, but... I'm not sure what
>to initialize the 'lock' member to.
Just use the SYSCTL_IN(
om the initial
allocation of the space, so don't expect differences in this area.
--
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
the other HP/PCL/whatever backends
in ghostscript.
Highly recommended!
--
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 incompe
In message <[EMAIL PROTECTED]>, "Daniel O'Connor" writes:
>
>On 10-Aug-2001 Poul-Henning Kamp wrote:
>> The new ghostscript 6.51 has integrated the HPIJS backends for HP printers.
>>
>> HPIJS is written by HP and contains most of their weird colo
uot;, or wrap it in _KERNEL? The comment in machine/signal.h(x86)
>says:
>
>#include/* codes for SIGILL, SIGFPE */
>
>but does that mean we must expose the entire contents of trap.h to
>userland? The problem is T_ is very common in lex source.
We most certainly shouldn't. E
replace the 14.318 MHz
xtal on the motherboard with a something more stable.
>PC hardware really sucks for timing.
Tell me about it...
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Nev
Solar Designer held a talk on this topic at HAL 2001,
>where they stated that backspaces could be detected, as a
>backspace actually translated to
>thus sending 3 characters at a time instead of only 1.
That's pretty BS because passwords are not echoed...
--
Poul-Henning Kamp
;Truly evil File System" :-)
It should be nuked now of course.
v_tag is only a debugging aid and it should be replaced by a "const char *"
instead so that we don't need to modify just to add a filesystem.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED
The v_tag has been abused a few places, easily recognizable by the fact
that the kernel should never inspect the value of v_tag.
These places should be easily changeable to use the new representation.
Please mark them with a big fat "/*XXX: ABUSE OF v_tag */" comment.
--
Poul-Henning Kam
In message <[EMAIL PROTECTED]>, Brent Verner writes:
>On 04 Sep 2001 at 10:36 (+0200), Poul-Henning Kamp wrote:
>|
>| Assignment:
>|
>| The v_tag element in struct vnode is a debugging aid, but unfortunately
>| it is implemented in a way which means that adding a files
vp->v_type = VBAD;
> }
>+ vp->v_flag |= VLOCKABLE;
> vp->v_data = de;
> de->de_vnode = vp;
> vn_lock(vp, LK_EXCLUSIVE | LK_RETRY, p);
>Index: fs/msdosfs/msdosfs_denode.c
>===
In message <[EMAIL PROTECTED]>, Maxim Sobolev writes:
>>
>> In message <[EMAIL PROTECTED]>, Brent Verner writes:
>> >On 04 Sep 2001 at 10:36 (+0200), Poul-Henning Kamp wrote:
>> >|
>> >| Assignment:
>> >|
>> >| The v_tag elem
r christs sake! What did you expect if not
revisionist $anything ?
Which reminds me, Adrian still oves us his story about ref :-)
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never att
In message <[EMAIL PROTECTED]>, Terry Lambert writes:
>Poul-Henning Kamp wrote:
>> Nate,
>>
>> You're replying to Terry for christs sake! What did you expect if not
>> revisionist $anything ?
>>
>> Which reminds me, Adrian still oves us his s
>> -
>> +#define VT_CODA "VT_CODA"
>...
>
> I don't think that the point of this is to use a string like
>that, but rather a descriptive string, i.e.
No actually not, I want something short and predictable like
"VT_CODA".
--
Poul-Henning Kamp
for details on NetGraph if you cannot find
any docs on it.
You may also want to look at the "musycc" and "if_mn" drivers which
support similar cards.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer
aph node names and physical devices which
>could be changed by issuing a control message to the Netgraph node. Perhaps this
>is a better alternative. I would welcome any suggestions you might have for
>handling this situation. Thanks again for your help...
>
>Andy
>
>Pou
These guys have 2 SCSI analyzers at $200 each:
http://www.metricsales.com/bargains.asp
--
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
number of children they have in the cache.
What ratio of files are reused as a function of them
being open or not.
What ratio of files are being reused as a function of
the number of pages they have in-core.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.2
to
directory pages, we wouldn't need the VFS-cache very much in the first
place...
--
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 explai
ook out for:
1. !ufs filesystems
2. inode->vnode hash/search algorithms may become much more
important.
--
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
s
843181 |898530 |778408 |involuntary context switches
-+-+-------
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-taho
do you think about
>it? In the meantime, I found another place in the kernel where VT_* macros are
>[ab]used - it is Linuxlator, attached please find patches to fix it - please
>review.
Sounds like a plan, and a quick eyeball of the patch shows no trouble.
Poul-Henning
--
Poul-Hennin
le it results in a 21.5% decrease.
>> :
>> :That's pretty darn significant: one out of every five I/O have
>> :been saved.
>
>Notice that both the user and system times increased..
Not significantly. As I already said: they are inside the standard
deviation and therefore
no guard page and
>no panic.
>If you would have a page fault there is no space where the CPU can
>write the state information to for entering the handler.
And it would take a double-fault for which we have a handler with
it's own stack.
--
Poul-Henning Kamp | UNIX since Zilog
In message <[EMAIL PROTECTED]>, "Dmitry S. Rzhavin" writes:
>Hi!
>Looks like jailed processes can't use udp or icmp, but can use tcp:
RTFM.
UDP works fine. ICMP and other raw socket magic doesn't.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[E
omedir. It was written to put the VM
usage under QUOTA control, but it had many useful side effects as well.
I can't seem to find it right now, but it is trivial to do: just
replace the sbrk(2) with mmap(). Only downside is the needed
filedescriptor which some shells don't like.
--
Poul-
mestamp edges on DCD, if the frequency is
more reasonable, that would work for you. Find RFC27xx for more info
about PPS-API.
--
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
be PERFECT) already
>implemented, or is this a spec for me to write for when modifying sio.c?
It's in sio.c already.
--
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
sible given the
>100Hz resolution of nanosleep() and friends.
>
> --Bart
>
--
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 adequ
rated in our tree
I can truly see how the workload would overwhelm you.
Submissions should contain a -current version or they are likely
to never make it into the tree...
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer |
ne tiresome email af the next about how good the world would
be if only we all listened more to you...
To tell the truth Terry, I think more work would get done here if
we didn't have to listen so much to five-star-arm-chair generals
like you.
--
Poul-Henning Kamp | UNIX since Zilog Zeus
wer-layer tools than
>tar, so they may possibly have layout information embedded in them.
>
>Is my assumption correct?
no.
Dump reads the raw device and finds everything by hand.
Restore (like tar!) just open/write/close/chown regular files.
--
Poul-Henning Kamp | UNIX since Zi
In message <[EMAIL PROTECTED]>, "Julian Stacey [EMAIL PROTECTED]
e" writes:
>"doc. dr. Marjan Mihelin, dipl. ing." wrote:
>> Hello,
>> We are using from 1993 Fiskars UPS 0.8 A UPS unit
Fiskars is part of Invensys/Powercom these days.
--
Poul-Hennin
In message <[EMAIL PROTECTED]>, Andrzej Bialecki writes:
>Poul-Henning Kamp wrote:
>>
>> In message <[EMAIL PROTECTED]>, "Julian Stacey [EMAIL PROTECTED]
>> e" writes:
>> >"doc. dr. Marjan Mihelin, dipl. ing." wrote:
>&g
es in the tree to test 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 PROT
m, you should have used nanotime(), not getnanotime().
getnanotime() returns a timestamp in nanoseconds of the last
stored timestamp which may be up to 1/hz seconds old.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer
In message <[EMAIL PROTECTED]>, Sansonetti Laurent
writes:
>Hi hackers,
>
>I have to hijack lpt_intr() from lpt device driver
>(/sys/dev/ppbus/lpt.c) to measure latency.
Uhm, why don't you simply use the pps driver ?
--
Poul-Henning Kamp | UNIX since Zilog Zeu
In message <[EMAIL PROTECTED]>, Sansonetti Laurent
writes:
>On Mon, 2001-11-12 at 16:28, Poul-Henning Kamp wrote:
>>
>> Uhm, why don't you simply use the pps driver ?
>>
>
>Yes, why not.. but I have the same problem : how to hijack current
>interrupt ha
gt;
> > louie
>
>Yes. Me too, but with a pamette, not a nic.
The "HotWorks" from www.vcc.com can do the same, a lot cheaper
and it has a FreeBSD driver: sys/pci/xrpu.c
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
F
ion at one of
my customers and I was actually considering running their collector
(if I can get my hands on it) just to see what the error rate is...
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
gt;much more consistent results.
For what it's worth I have disabled newreno at my customer sites as well
and felt and heard less "bogosity" since.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer | BSD
>whole bunch of network traffic) it has yielded a good 4-5 times better
>performance than any other alternative I've found.
I have to agree here.
Netgraph has some shortcomings, but performance is not one of them.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECT
new card which could trivially be modified to run under FreeBSDs
driver, but so far they have not sent me a card...
etinc is not recommendable.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Neve
adapt the driver
but no such luck yet.
--
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
so much grief in our mailing lists
without ever actually submitting one single diff to us is not
a (re)commendable supplier.
--
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
.
You're of course just as free to decide what you do.
>I dont see how driving away commercial vendors with such a ridiculous
>attitude benefits the FreeBSD community. Very unprofessional.
Belive me, I have worked hard to drive Dennis away :-)
--
Poul-Henning Kamp | UNIX since
In message <[EMAIL PROTECTED]>, Len Conrad
writes:
>Back on the original topic, anybody know the retail for this card:
>
>http://www.sbei.net/wanadapt1t1e1.htm
Why don't you call them ?
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] |
rontend. We also have drivers for the MUSYCC
from Conexant.
--
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.
T
te a new one from scratch.
We want something with an integral T1/E1 DSU/CSU, otherwise cost is
still prohibitive.
--
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
lable for the job.
I don't know how similar they are, either way, all the work on the if_mn
and musycc drivers were in the framers and clocking. The HDLC is just
a piece of cake...
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeB
hmm - Poul, do you how what the reference boards were that these
>drivers were tested/developed with?
Yes I know (since I wrote them :-)
The MUNICHX driver were written on the "EASY321" eval kit from Siemens
(Now Infinieon) and the MUSYCC was written on LMC's 1504 card which
is now
will be able to produce new versions of the
driver if the company goes titsup.com or gets bought by M$ or
whatever...
Over and out...
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
fully agree with Jordan btw, that is a very clear explanation of
the situation. And as I said, we do have precedence and procedures
for shipping binary drivers with FreeBSD.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer
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
401 - 500 of 654 matches
Mail list logo
