Am 25.09.11 22:11, schrieb Ken Hornstein:
>> Sure. I plan to remove the old API, which has not been documented for
>> quite a while:
>
> In fairness ... "quite a while" is a bit misleading. The "old" API was
> the only API available as of the last release of NetBSD. Okay, that
> release was a w
On Mon, 29 Aug 2011 01:07:52 +0200
Alistair Crooks wrote:
Sorry for replying to an old thread, I'm still catching up with mail :)
> > i've found this some what annoying. IMO, we should have a a way to say
> > "let normal users do this". i'm not sure sysctl is the right place, but
> > maybe an
On 26.09.2011 00:21, Joerg Sonnenberger wrote:
On Sun, Sep 25, 2011 at 11:28:18PM +0200, Jean-Yves Migeon wrote:
On 25.09.2011 20:17, Joerg Sonnenberger wrote:
Just to practical notes:
(1) Please test that lint(1) is not stupid enough to bail out on it.
(2) Kill the !__STDC__ branches. Prefera
On Sun, Sep 25, 2011 at 11:28:18PM +0200, Jean-Yves Migeon wrote:
> On 25.09.2011 20:17, Joerg Sonnenberger wrote:
> >>>Just to practical notes:
> >>>
> >>>(1) Please test that lint(1) is not stupid enough to bail out on it.
> >>>(2) Kill the !__STDC__ branches. Preferable doing this first.
> >>
>
On Fri, 9 Sep 2011 09:38:31 -0400
Matthew Mondor wrote:
> On Fri, 9 Sep 2011 00:26:43 + (UTC)
> chris...@astron.com (Christos Zoulas) wrote:
>
> > Please file a PR about this. I've been meaning to fix it.
>
> Thanks, I will.
For reference and to close this thread, the relevant PR was kern/
On 25.09.2011 20:17, Joerg Sonnenberger wrote:
Just to practical notes:
(1) Please test that lint(1) is not stupid enough to bail out on it.
(2) Kill the !__STDC__ branches. Preferable doing this first.
(1) How do I check that? Run a distribution with MKLINT=yes would be enough?
make subr_pr
>Sure. I plan to remove the old API, which has not been documented for
>quite a while:
In fairness ... "quite a while" is a bit misleading. The "old" API was
the only API available as of the last release of NetBSD. Okay, that
release was a while ago, but if you're like me and generally only use
On Sun, Sep 25, 2011 at 07:28:17PM +0200, Jean-Yves Migeon wrote:
> On 25.09.2011 16:27, Joerg Sonnenberger wrote:
> >On Sun, Sep 25, 2011 at 04:02:04PM +0200, Jean-Yves Migeon wrote:
> >>Unless someone objects (with arguments), I will commit this at the
> >>end of the week and fix call sites to us
On 25.09.2011 16:27, Joerg Sonnenberger wrote:
On Sun, Sep 25, 2011 at 04:02:04PM +0200, Jean-Yves Migeon wrote:
Unless someone objects (with arguments), I will commit this at the
end of the week and fix call sites to use the new macro;
KASSERTMSG() would then work like its man page suggests.
On 09/25/11 18:59, Edgar Fuß wrote:
the user has to use gpioctl(8) for HW support and gpiopwm(4) for SW
implementation
Couldn't gpiopwm(4) just use the HW version if that is available?
if the HW supports pulsating, there is no need to attach the gpiopwm(4)
driver.
> the user has to use gpioctl(8) for HW support and gpiopwm(4) for SW
> implementation
Couldn't gpiopwm(4) just use the HW version if that is available?
On 09/25/11 16:50, Jachym Holecek wrote:
# Marc Balmer 2011-09-25:
I recently added code to gpio(4) on jak's request to pulse a pin in
software. The idea is, that when the hardware supports it, a pin is
pulsed by the hardware, if the underlying hardware has no pulsate
support, it can be done in
# Marc Balmer 2011-09-25:
> I recently added code to gpio(4) on jak's request to pulse a pin in
> software. The idea is, that when the hardware supports it, a pin is
> pulsed by the hardware, if the underlying hardware has no pulsate
> support, it can be done in software. While the current code w
On Sun, Sep 25, 2011 at 04:02:04PM +0200, Jean-Yves Migeon wrote:
> Unless someone objects (with arguments), I will commit this at the
> end of the week and fix call sites to use the new macro;
> KASSERTMSG() would then work like its man page suggests.
Just to practical notes:
(1) Please test tha
On 17.09.2011 01:09, Jean-Yves Migeon wrote:
[snip]
Summary about my discussion regarding KASSERTMSG(): in its current form
it cannot append the msg passed as argument to it to the panic format
string, which makes it rather impractical: we fail to log the file,
line, expression that triggered th
On 24.09.2011 22:35, Francois Tigeot wrote:
[snip]
While learning how to use proplib, I've found an inconsistency between the
documentation and the actual kernel implementations:
the manual page for prop_array_send_syscall, prop_array_recv_syscall,
prop_dictionary_send_syscall and prop_dictionar
I recently added code to gpio(4) on jak's request to pulse a pin in
software. The idea is, that when the hardware supports it, a pin is
pulsed by the hardware, if the underlying hardware has no pulsate
support, it can be done in software. While the current code works, I
think it is done wrong, or
On Sun, Sep 25, 2011 at 10:50:44AM +0200, Alan Barrett wrote:
> On Sun, 25 Sep 2011, Jukka Ruohonen wrote:
> >So here is a quick draft for the first iteration with the cpuctl(8). If
> >there
> >are issues, speak now, otherwise I'll proceed with something based on this.
>
> You forgot to include t
On Sun, 25 Sep 2011, Jukka Ruohonen wrote:
So here is a quick draft for the first iteration with the cpuctl(8). If there
are issues, speak now, otherwise I'll proceed with something based on this.
You forgot to include the documentation.
--apb (Alan Barrett)
On Sat, Sep 24, 2011 at 07:53:47PM +0200, Joerg Sonnenberger wrote:
> I was listening possible decision making factors. Depending on your
> environment, you have all or none of them. The main point is that good
> decision making needs more than just "You can toogle this".
So here is a quick draft
Am 25.09.2011 um 00:31 schrieb Ken Hornstein:
>> gpio(4) isn't in any release, right? you're almost certainly the
>> major user so far, i don't think there's much benefit to backwards
>> comapt code here.
>
> gpio(4) is in at least NetBSD 5.0.1. Actually, I also see it on a
> NetBSD 4.0.1 syst
21 matches
Mail list logo
