> On Fri 2023-07-14 08:12, Jason Thorpe wrote:
> >
> > The typedef itself buys you nothing but a few charactes less to type,
>
> No, that’s not correct. For a type that’s meant to be “opaque” (i.e. “users
> of the interface should not have to know or
> care about any of the implementation
David Holland wrote:
>> I would say so, especially since that would mean the child's parent is
> > no longer the process that forked it (which could break other use
>> cases).
>
> That depends on how you implement detaching, but I suppose ultimately
> it's important for getppid() to revert to 1
Robert Swindells wrote:
> I posted a few weeks ago that I could reboot my Pinebook by doing:
>
> % cat /dev/video0 > foo.jpg
>
> I have now got it to drop into DDB and found that it is triggering an
> assertion in sys/arch/arm/arm32/bus_dma.c:_bus_dmamap_sync().
>
>KASSERTMSG(len > 0 &&
> Jason Thorpe wrote:
While I agree that it’s not exactly difficult to maintain the a.out exec
package, I do wonder if there is anyone out there actually running ancient
a.out binaries.
>>>
>>> NetBSD 0.9 i386 a.out yes.
>>
>> Here, too.
>
> Well, then you have my
Kamil Rytarowski wrote:
>> While I agree that it’s not exactly difficult to maintain the a.out exec
>> package, I do wonder if there is anyone out there actually running ancient
>> a.out binaries.
>>
>
> NetBSD 0.9 i386 a.out yes.
Here, too.
Emmanuel Dreyfus wrote:
> > That part of your change is puerly cosmetic,
>
> The idea was to be consistent everywhere we loop on ports.
For what it's worth, the USB spec (especially 3.x) uses origin-1 port
numbers. This is true from USB 1.0 in the hub commands, but starting with
USB 3.0
Emmanuel Dreyfus wrote:
> I did not post the whole patch for the sake of clarity, but it seems it
was a
> mistake. Please find it below.
>
> The substituted values are chosen based on vendorId/producId obtained
earlier
> from the device descriptor (which fortunately does not get corrupted). If
one
: tech-kern-ow...@netbsd.org On Behalf Of
Emmanuel Dreyfus
Sent: Tuesday, October 16, 2018 19:19
To: Terry Moore
Cc: tech-kern@netbsd.org
Subject: Re: Reboot resistant USB bug
Terry Moore wrote:
> Also, some descriptor-gets will normally fail, and it's important to pass
> the f
Speaking as a USB host-stack person: it's a bad idea to assume that a device
has not changed after a reboot of the system.
Also, some descriptor-gets will normally fail, and it's important to pass
the failure to the caller. So I believe that your fix will have unforeseen
side-effects.
It is
>> The real keyboards are PS/2 and I can't change that because it runs
>> on a wire physically passing a /real/ firewall, [...]
>
>(a) Is it possible to run USB over the same conductors used by the PS/2
>cable? (This is a real question; I don't know enough about layer 1 of
>either to answer it.)
> I think you are confusing spectre and meltdown.
Yes, my apologies.
--Tery
Hi,
> In a cross-platform process utility tool the question came up how to
decide if a process is 64-bit.
>
> https://github.com/giampaolo/psutil/issues/1102
>
> What's the best answer for NetBSD?
If I understand correctly, you want psutil-based scripts -- which seem to
be written in Python --
>> > Is it possible to use a USB port as a USB slave? I would like to
>> > make it act as a keyboard to output some data to another machine.
> Isn't there already a slave side USB driver for emulated ethernet for
StrongARM/PXA devices ?
Hi all,
As the lurking member of USB-IF, and someone who
> So when I open /dev/ugen1.02 and read, it uses 0x82, but if I write, it
> uses 0x02? Or at least it should? Because there is no /dev/ugen1.130
> or any such - nor does the minor-number cracking code in the driver
> show anything of the sort.
That is what I would guess.
> Ooo. So an
[apologies in advance, I'm using Outlook which really is annoying for plain
text/list responses. Let me know if I should have hard-wrapped the
line-endings, I forget the convention.]
> So the "intf 1 ep 0" endpoint is actually the same thing as the "intf 2
> ep 1" endpoint, because they're both
The following might or might not be helpful.
Endpoint *addresses* are a flat space in USB. Endpoint *indices* within
interface are almost never used. If your device doesn't have multiple
configuration or multiple alternate settings, the endpoint address is
enough. Endpoint (index) 3 of interface
Will the hang occur if make dies due to a signal (control-C, or kill -9, for
example)?
--Terry
> -Original Message-
> From: tech-kern-ow...@netbsd.org [mailto:tech-kern-ow...@netbsd.org] On
> Behalf Of Paul Goyette
> Sent: Thursday, January 7, 2016 17:00
> To: Taylor R Campbell
Not only legitimate, but required, depending on the class protocol.
Best regards,
--Terry
> -Original Message-
> From: tech-kern-ow...@netbsd.org [mailto:tech-kern-ow...@netbsd.org] On
> Behalf Of Greg Troxel
> Sent: Wednesday, December 30, 2015 17:36
> To: Brian Buhrow
> > Well, we love Brainy and we always give it credit (or at least try to)!
> >
> > christos
>
> Yep!
>
> I'm just wondering when Max packages up the Brainy tool and starts
> getting customers to actually pay for it! It really is one very
> excellent tool.
+1
-Original Message-
From: tech-kern-ow...@netbsd.org [mailto:tech-kern-ow...@netbsd.org] On
Behalf Of Kengo NAKAHARA
Sent: Sunday, May 17, 2015 23:58
To: tech-kern@netbsd.org; t...@mcci.com
Cc: chris...@astron.com
Subject: Re: change MSI/MSI-X APIs
I'm sure there are even better
From: tech-kern-ow...@netbsd.org [mailto:tech-kern-ow...@netbsd.org] On
Behalf Of Kengo NAKAHARA
Hi
On 2015/05/11 23:18, Christos Zoulas wrote:
Can't we have a:
int pci_intr_map(struct pci_attach_args *pa, pci_intr_handle_t *ih);
for the drivers that have only one interrupt,
-Original Message-
From: Hisashi T Fujinaka [mailto:ht...@twofifty.com]
Sent: Sunday, August 31, 2014 12:39
To: Terry Moore
Cc: tech-kern@netbsd.org
Subject: RE: FW: ixg(4) performances
I may be wrong in the transactions/transfers. However, I think you're
reading the page
From Emmanuel Dreyfus
You are right;
# pcictl /dev/pci5 read -d 0 -f 1 0xa8
00092810
# pcictl /dev/pci5 write -d 0 -f 1 0xa8 0x00094810
# pcictl /dev/pci5 read -d 0 -f 1 0xa8
4810
That's reassuring. The dump confirms that we're looking at the right
registers, thank you.
As I read the
-Original Message-
From: Hisashi T Fujinaka [mailto:ht...@twofifty.com]
Sent: Saturday, August 30, 2014 21:29
To: Terry Moore
Cc: tech-kern@netbsd.org
Subject: Re: FW: ixg(4) performances
Doesn't anyone read my posts or, more important, the PCIe spec?
2.5 Giga TRANSFERS per
Forgot to cc the list.
-Original Message-
From: Terry Moore [mailto:t...@mcci.com]
Sent: Friday, August 29, 2014 15:13
To: 'Emmanuel Dreyfus'
Subject: RE: ixg(4) performances
But it's running at gen1. I strongly suspect that the benchmark case
was
gen2 (since the ixg is capable
-Original Message-
From: tech-kern-ow...@netbsd.org [mailto:tech-kern-ow...@netbsd.org] On
Behalf Of Emmanuel Dreyfus
Sent: Thursday, August 28, 2014 23:55
To: Terry Moore; 'Christos Zoulas'
Cc: tech-kern@netbsd.org
Subject: Re: ixg(4) performances
Terry Moore t...@mcci.com
On Friday, August 29, 2014 11:51, Emmanuel Dreyfus wrote:
On Fri, Aug 29, 2014 at 08:48:51AM -0400, Terry Moore wrote:
Still, you should check whether you have the right number of the right
generation of PCIe lanes connected to the ixg.
I found this, but the result does not make sense
Or the performance are constrained by something unrelated. In the blog
post cited above, the poster acheived more than 5 Gb/s before touching
MMRBC, while I am stuck at 2,7 GB/s. Any new idea welcome.
The blog post refers to PCI-X, I'm more familiar with PCIe, but the concepts
are similar.
From: Marc Balmer [mailto:m...@msys.ch]
It's not *much* less safe than compiling and executing a string in the
kernel. The only additional attack surfaces are that you can write
things
that the compiler wouldn't write. This can (1) cause a crash at load
time,
or it can (2) cause
Am 17.11.13 22:03, schrieb Terry Moore:
From: Marc Balmer [mailto:m...@msys.ch]
It's not *much* less safe than compiling and executing a string in the
kernel. The only additional attack surfaces are that you can write
things
that the compiler wouldn't write. This can (1) cause a crash
I believe that if you want the Lua scripts to be portable across NetBSD
deployments, you should choose a well-known fixed width.
Watch out, by the way, for compiled scripts; I have not checked Lua 5.x, but
you may find if not careful that the compiled binary is not loadable on
machines with
From: Lourival Vieira Neto [mailto:lourival.n...@gmail.com]
Watch out, by the way, for compiled scripts; I have not checked Lua 5.x,
but
you may find if not careful that the compiled binary is not loadable on
machines with different choices for LP64, ILP32, etc. This is somewhat
Hi all,
I do USB for a living.
USB is not a very good way to do PPS synchronization if you're looking for
usec resolution -- there are huge and unpredictable delays that can be
introduced from a number of sources.
Some of the sources are inherent and some are due to system issues.
Sources of
-kern-ow...@netbsd.org [mailto:tech-kern-ow...@netbsd.org] On
Behalf Of Greg Troxel
Sent: Friday, November 01, 2013 15:30
To: Terry Moore
Cc: tech-kern@NetBSD.org
Subject: Re: pulse-per-second API status
Thanks for the comments.
Terry Moore t...@mcci.com writes:
USB is not a very good
Yet again, this whole story just makes me wonder why AWK has never
evolved to be more powerful language for this kind of purpose (Perl is
not the direction I am talking about). Certainly, simplicity of AWK
is valued. However, it does not mean that it should have just stopped
evolving at
Just to clarify a bit
Indeed, we started with Lua because AWK was not embeddable and because of
the 1-origin issue.
We thought, mistakenly, that a language that didn't look very much like C
would cause fewer problems because of the 0-origin / 1-origin difference.
Apparently, however, it's
HI,
I'm replying to a message that was on tech-userlevel@. I'm not sure why a
discussion of in-kernel Lua was on tech-userlevel@. I see that other related
messages were on tech-kern@, so I'm posting my reply there.
My company has quite a bit of experience using Lua as a scripting language
--
Sorry, misread original comment -- C89 appeared as C99. Old eyes can be
as bad as old ears for intelligent discussion
--Terry
t...@mcci.comtel: +1-607-277-1029fax: +1-607-277-6844www.mcci.com
On 2/18/2010 8:18 AM, Iain Hibbert wrote:
On Thu, 18 Feb 2010, Terry Moore wrote
38 matches
Mail list logo
