> > seems to work, although I still have some stability issues with
> > dynamically attaching/detaching a usb keyboard. For your reference I
>
> would you share with us what sort of issues you are having? feel free to
> move this into private email if you are not comfortable discussing it on
> publ
In message: <[EMAIL PROTECTED]>
"M. Warner Losh" <[EMAIL PROTECTED]> writes:
: In message: <[EMAIL PROTECTED]>
: Joerg Sonnenberger <[EMAIL PROTECTED]> writes:
: : The compiler can only optimize it away if it is known to be a constant.
: : But thinking again about it, it sho
In message: <[EMAIL PROTECTED]>
Mike Hunter <[EMAIL PROTECTED]> writes:
: Is the pre-zeroing of malloc'd memory documented somewhere? By my reading
: of the malloc manapge...
:
: The calloc() function allocates space for number objects, each size
: bytes in length. The re
In message: <[EMAIL PROTECTED]>
Joerg Sonnenberger <[EMAIL PROTECTED]> writes:
: The compiler can only optimize it away if it is known to be a constant.
: But thinking again about it, it should be documented at least whether
: a count of 0 is allowed or not. I think it makes more sense
In message: <[EMAIL PROTECTED]>
Hans Petter Selasky <[EMAIL PROTECTED]> writes:
: Where is it documented?
NetBSD's man page:
...
These functions will never fail. If they would fail (e.g., because of an
argument error), that indicates a software bug which should cause a
M. Warner Losh wrote:
In message: <[EMAIL PROTECTED]>
Hans Petter Selasky <[EMAIL PROTECTED]> writes:
: So can someone have this fixed, or is there a reason not to fix it. The one
: who wrote the code has done the same mistake with every one of the
: bus_space_ that does memory
In message: <[EMAIL PROTECTED]>
Hans Petter Selasky <[EMAIL PROTECTED]> writes:
: On Tuesday 14 June 2005 01:23, M. Warner Losh wrote:
: > In message: <[EMAIL PROTECTED]>
: >
: > Hans Petter Selasky <[EMAIL PROTECTED]> writes:
: > : So can someone have this fixed, or is ther
In message: <[EMAIL PROTECTED]>
Hans Petter Selasky <[EMAIL PROTECTED]> writes:
: So can someone have this fixed, or is there a reason not to fix it. The one
: who wrote the code has done the same mistake with every one of the
: bus_space_ that does memory mapped I/O. It currently
On Tue, 14 Jun 2005 06:14, Jeremie Le Hen wrote:
> This is true, prioritizing ACKs is very useful when you want to download
> with full speed while uploading. But I tend to agree with Baldur's idea
> too : I give HTTP and DNS requests as well as interactive SSH session
> (TOS field set to "low del
On Tuesday 14 June 2005 01:23, M. Warner Losh wrote:
> In message: <[EMAIL PROTECTED]>
>
> Hans Petter Selasky <[EMAIL PROTECTED]> writes:
> : So can someone have this fixed, or is there a reason not to fix it. The
> : one who wrote the code has done the same mistake with every one of t
On Monday 13 June 2005 18:27, Joerg Sonnenberger wrote:
> On Mon, Jun 13, 2005 at 05:58:24PM +0200, Hans Petter Selasky wrote:
> > static void
> > filter(struct fifo *f)
> > {
> > do {
> > if(!f->len)
> > {
> > if(f->m) ...;
> >
> > f->m = get_mbuf();
> > if(!
On Jun 13, "Erik Trulsson" wrote:
> > Is the pre-zeroing of malloc'd memory documented somewhere? By my reading
> > of the malloc manapge...
> >
> > The calloc() function allocates space for number objects, each size
> > bytes in length. The result is identical to calling malloc() w
Hi Devon, hi Baldur,
(this thread would better seat on -net@, IMO)
> >>So, i haven't found a way to make this happen, i googled
> >>for it but didn't find anything. Does PF or IPFW have this
> >>feature?
>
> I'm not sure the rationale is appropriate, though. You should be more
> worried about p
Mike Hunter <[EMAIL PROTECTED]> writes:
> Is the pre-zeroing of malloc'd memory documented somewhere? By my reading
> of the malloc manapge...
malloc() does not pre-zero memory, but it hands you memory which has
been pre-zeroed by the kernel unless you've used it before. Your test
program makes
On Mon, Jun 13, 2005 at 12:55:40PM -0600, Scott Long wrote:
> >Lot's of driver use file->private to get at per-device data easily,
> >but that's just a shortcut.
>
> Ok, I thought that you were talking about per-process data being in the
> file descriptor.
Can't be done.
FWIW, the main differenc
On Mon, Jun 13, 2005 at 08:59:17PM +0100, Christoph Hellwig wrote:
> disk drivers use a completely different set of entry points in Linux,
> and don't have access to per-fd data even in the case they're opened
> from userland. Character drivers to which this applies OTOH always
> get a valid struc
On Mon, Jun 13, 2005 at 12:54:40PM -0700, Julian Elischer wrote:
> though, some people use it for that purpose (e.g. in the original posting).
driver writers do all kinds of odd things ;-)
> it might not be such a bad idea..
> I don't see why the device entrypoints shouldn't have that argument
>
Christoph Hellwig wrote:
On Mon, Jun 13, 2005 at 12:55:40PM -0600, Scott Long wrote:
Lot's of driver use file->private to get at per-device data easily,
but that's just a shortcut.
Ok, I thought that you were talking about per-process data being in the
file descriptor.
No, L
On Mon, Jun 13, 2005 at 12:31:50PM -0700, Mike Hunter wrote:
> On Jun 11, "Dag-Erling Smrgrav" wrote:
>
> > Mike Hunter <[EMAIL PROTECTED]> writes:
> > > I have a feeling that I'm missing something really obvious, but I'm having
> > > trouble understanding why the following program:
> > > [...]
>
Scott Long wrote:
Christoph Hellwig wrote:
On Mon, Jun 13, 2005 at 10:50:26AM -0700, Julian Elischer wrote:
Several times in the past we've seen people complainign that Linux
allows a device driver to know
who called it and somehow it seems to store somewhere some
information about who
op
Mike Hunter <[EMAIL PROTECTED]> wrote:
>On Jun 11, "Dag-Erling Smrgrav" wrote:
>> Mike Hunter <[EMAIL PROTECTED]> writes:
>> > I have a feeling that I'm missing something really obvious, but I'm having
>> > trouble understanding why the following program:
>> > [...]
>> > Never prints anything but "
On Jun 11, "Dag-Erling Smrgrav" wrote:
> Mike Hunter <[EMAIL PROTECTED]> writes:
> > I have a feeling that I'm missing something really obvious, but I'm having
> > trouble understanding why the following program:
> > [...]
> > Never prints anything but "0"'s.
>
> Because the kernel always hands p
Christoph Hellwig wrote:
On Mon, Jun 13, 2005 at 12:55:40PM -0600, Scott Long wrote:
Lot's of driver use file->private to get at per-device data easily,
but that's just a shortcut.
Ok, I thought that you were talking about per-process data being in the
file descriptor.
No, Linux has absol
On Mon, Jun 13, 2005 at 12:55:40PM -0600, Scott Long wrote:
> >Lot's of driver use file->private to get at per-device data easily,
> >but that's just a shortcut.
>
> Ok, I thought that you were talking about per-process data being in the
> file descriptor.
No, Linux has absolutely no concept of p
Christoph Hellwig wrote:
On Mon, Jun 13, 2005 at 12:37:07PM -0600, Scott Long wrote:
How does linux handle the implications of fork(2) in this scenario?
it's still counted as the same instance. Similar for dup or passing
descriptors over AF_UNIX sockets. The data is explictly not per-proce
On Mon, Jun 13, 2005 at 12:37:07PM -0600, Scott Long wrote:
> How does linux handle the implications of fork(2) in this scenario?
it's still counted as the same instance. Similar for dup or passing
descriptors over AF_UNIX sockets. The data is explictly not per-process
but per instance.
There's
Baldur Gislason wrote:
IPFW does have a queue feature which is a part of dummynet.
You can match packets based on size and send them to different queues.
Baldur
On Mon, Jun 13, 2005 at 09:36:57PM +0300, Erik Udo wrote:
I came across this idea for prioritizing small
IP packets, so that for exa
IPFW does have a queue feature which is a part of dummynet.
You can match packets based on size and send them to different queues.
Baldur
On Mon, Jun 13, 2005 at 09:36:57PM +0300, Erik Udo wrote:
> I came across this idea for prioritizing small
> IP packets, so that for example HTTP requests,
> g
Christoph Hellwig wrote:
On Mon, Jun 13, 2005 at 10:50:26AM -0700, Julian Elischer wrote:
Several times in the past we've seen people complainign that Linux
allows a device driver to know
who called it and somehow it seems to store somewhere some information
about who
openned the device.. tho
I came across this idea for prioritizing small
IP packets, so that for example HTTP requests,
game packets and other small, but importat packets
would get uploaded before the big packets. Big files
are usually uploaded in bigger packets, right?
So, i haven't found a way to make this happen, i goo
On Mon, Jun 13, 2005 at 05:58:24PM +0200, Hans Petter Selasky wrote:
> static void
> filter(struct fifo *f)
> {
> do {
> if(!f->len)
> {
> if(f->m) ...;
>
> f->m = get_mbuf();
> if(!f->m) break;
>
> f->len = m->m_len;
> f->ptr = m->m_data;
On Mon, Jun 13, 2005 at 10:50:26AM -0700, Julian Elischer wrote:
>
> Several times in the past we've seen people complainign that Linux
> allows a device driver to know
> who called it and somehow it seems to store somewhere some information
> about who
> openned the device.. thos somehow allows
2nd try to answer this..
Apache Xie wrote:
I have some experiences in writing Linux device driver,
but I am new to FreeBSD kernel, although from the first
glimpse, there seems no big differences between the kernel
operations a char device driver can use, but I met some
problems when the driver
Daniel Eischen wrote:
On Mon, 13 Jun 2005, Julian Elischer wrote:
Maybe I don't understand the problem but..
I think the problem is that you want to keep a separate buffer for each
user,
while the drivers you are looking at expect to have only one buffer per
device.
One answer to this
On Mon, 13 Jun 2005, Julian Elischer wrote:
>
> Maybe I don't understand the problem but..
>
> I think the problem is that you want to keep a separate buffer for each
> user, ]
> while the drivers you are looking at expect to have only one buffer per
> device.
>
> One answer to this would be to mak
Apache Xie wrote:
I have some experiences in writing Linux device driver,
but I am new to FreeBSD kernel, although from the first
glimpse, there seems no big differences between the kernel
operations a char device driver can use, but I met some
problems when the driver is running in FreeBSD.
Hi Everyone,
I thought I'd forward this, in case there is someone interested in
working on SCSI tape support.
Andrew Hume wrote in the June 2005 ";login":
For outright bugs, two examples come to mind. The first is
the weakness of the FreeBSD SCSI system; we cannot reliably
write t
Hi Norbert,
you also might want to look at experimental keyboard mux drivers.
it is based on vkbd(4) and uses the idea of one super-keyboard that
consumes scancodes from other keyboards. there are still a few
issues i need to fix, but, in general, it works.
http://www.geocities.com/m_evmenkin/k
On Monday 13 June 2005 14:44, Joerg Sonnenberger wrote:
> On Mon, Jun 13, 2005 at 02:12:38PM +0200, Hans Petter Selasky wrote:
> > This is equivalent to:
> >
> > while(--count)
> > {
> > /* I/O */
> > }
> >
> > which is obviously wrong, because it doesn't check for count equal to
> > zero.
>
> Wh
From: Mark Tinguely <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED], freebsd-hackers@freebsd.org
Subject: Re: contigmalloc() and mmap()
Date: Mon, 13 Jun 2005 07:41:33 -0500 (CDT)
> I browsed kernel tree, I found those drivers which use contigmalloc()
and
> contigfree() always call these two ker
> >So
> >how can I fix this in assembly. I am not an expert with inlined assembly,
> >so
> >maybe someone can correct me if I am wrong, but something like this needs
> >to
> >be added:
> >
> >or %ecx, %ecx
> >jz 2
> >
> >2:
>
> This is wrong beacause the result is stored in ecx. Better using
> JECX
On Mon, Jun 13, 2005 at 02:12:38PM +0200, Hans Petter Selasky wrote:
> This is equivalent to:
>
> while(--count)
> {
> /* I/O */
> }
>
> which is obviously wrong, because it doesn't check for count equal to
> zero.
Why do you think it is a bug? It is part of the interface contract and
useful t
On Fri, Jun 10, 2005 at 04:57:50PM -0700, Matthew Dillon wrote:
>
> You think that is bad, try running 'rain' on an xterm!
HAHA. Not only xterm, normal console is good enough :)
Joerg
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebs
>http://www.freebsd.org/cgi/query-pr.cgi?pr=80980
>
>In FreeBSD 6-current the code for "bus_space_write_multi_1()" says:
>
>__asm __volatile(" \n\
>cld \n\
>1: lodsb
Hi,
I stumbled across this bug a year ago, but still none has managed to fix it.
Instead the PR got lost and I am now posting it a second time:
http://www.freebsd.org/cgi/query-pr.cgi?pr=80980
In FreeBSD 6-current the code for "bus_space_write_multi_1()" says:
__asm __volatile(
So, again, please send Your opinions on this idea. Do You think
this (+ all needed utilities to do statistics etc) would be
applicable to Summer Of Code "Tracking performance over time" project?
A very good (and simple) way to track and plot peformance over
time is Orca. You only need t
Hello Hackers!
I have an idea which could be used to track FreeBSD performance and regression
testing. Please take a look and give Your opinion on how usefull that would be
for the FreeBSD project.
The basis for this system would be hijacking certain functions execution with
injected code. H
yeah, thanks. I'm subscribed to performance also - it's kinda dead over there.
I'll check the archives also, thanks.
Ray
At 11:42 AM 6/13/2005 +0200, Julian H. Stacey wrote:
| [EMAIL PROTECTED] wrote:
| > Hello list,
| >
| > I've recently been doing quite a few benchmarks with regard to PHP
I have some experiences in writing Linux device driver,
but I am new to FreeBSD kernel, although from the first
glimpse, there seems no big differences between the kernel
operations a char device driver can use, but I met some
problems when the driver is running in FreeBSD.
Our device is an exper
> you also might want to look at experimental keyboard mux drivers. it is
> based on vkbd(4) and uses the idea of one super-keyboard that consumes
> scancodes from other keyboards. there are still a few issues i need to
> fix, but, in general, it works.
>
> http://www.geocities.com/m_evmenkin/k
Hello list,
I've recently been doing quite a few benchmarks with regard to PHP and Apache,
as well as stripping down the Kernel on 5.3 and 5.4 to improve performance for
web/application servers.
My question is: I was wondering if anyone out there has ever done a head to head
test of 4.11 to 5
> > Else if devd is not available on 4.11 you will have to change
> > some code and
> > compile a new kernel, from what I can see.
> >
> > To the file /sys/dev/usb/ukbd.c add this:
> >
> > static void
> > usbd_add_device_detach_event(device_t self)
> > {
> >struct usb_event ue;
> >
> >bzero
52 matches
Mail list logo
