Module Name:src
Committed By: hans
Date: Tue Mar 4 17:00:28 UTC 2025
Modified Files:
src/sys/dev/dec: dzkbd.c
Log Message:
dzkbd: set the keyboard type according to what lk201_init() detected
This makes wsconsctl report the correct keyboard type. The layout is
still hard
Module Name:src
Committed By: hans
Date: Tue Mar 4 17:00:28 UTC 2025
Modified Files:
src/sys/dev/dec: dzkbd.c
Log Message:
dzkbd: set the keyboard type according to what lk201_init() detected
This makes wsconsctl report the correct keyboard type. The layout is
still hard
Module Name:src
Committed By: hans
Date: Tue Mar 4 16:18:27 UTC 2025
Modified Files:
src/sys/dev/dec: dzkbd.c
Log Message:
dzkbd: perform keyboard initialization again for console keyboards
Also, initialize dzkbd_console_internal properly. Makes keyboard type
detection w
Module Name:src
Committed By: hans
Date: Tue Mar 4 16:18:27 UTC 2025
Modified Files:
src/sys/dev/dec: dzkbd.c
Log Message:
dzkbd: perform keyboard initialization again for console keyboards
Also, initialize dzkbd_console_internal properly. Makes keyboard type
detection w
Module Name:src
Committed By: tsutsui
Date: Wed Feb 14 12:59:44 UTC 2024
Modified Files:
src/sys/dev/dec: lk201_ws.c lk201var.h
Log Message:
Use proper macro for return values and remove #if 0'ed out block.
Mostly from OpenBSD/vax. No binary changes.
To generate a diff
Module Name:src
Committed By: tsutsui
Date: Wed Feb 14 12:59:44 UTC 2024
Modified Files:
src/sys/dev/dec: lk201_ws.c lk201var.h
Log Message:
Use proper macro for return values and remove #if 0'ed out block.
Mostly from OpenBSD/vax. No binary changes.
To generate a diff
Module Name:src
Committed By: tsutsui
Date: Wed Feb 14 12:49:47 UTC 2024
Modified Files:
src/sys/dev/dec: dzkbd.c
Log Message:
Fix a fatal typo that causes dzkbd_cngetc() to stall.
Should be pulled up to netbsd-10 and netbsd-9.
To generate a diff of this commit:
cvs rdi
Module Name:src
Committed By: tsutsui
Date: Wed Feb 14 12:49:47 UTC 2024
Modified Files:
src/sys/dev/dec: dzkbd.c
Log Message:
Fix a fatal typo that causes dzkbd_cngetc() to stall.
Should be pulled up to netbsd-10 and netbsd-9.
To generate a diff of this commit:
cvs rdi
Module Name:src
Committed By: tsutsui
Date: Fri Feb 2 15:44:43 UTC 2024
Modified Files:
src/sys/dev/dec: dz.c dzkbd.c dzms.c mcclock.c
Log Message:
Use aprint_normal(9) for attach messages.
To generate a diff of this commit:
cvs rdiff -u -r1.43 -r1.44 src/sys/dev/dec/dz
Module Name:src
Committed By: tsutsui
Date: Fri Feb 2 15:44:43 UTC 2024
Modified Files:
src/sys/dev/dec: dz.c dzkbd.c dzms.c mcclock.c
Log Message:
Use aprint_normal(9) for attach messages.
To generate a diff of this commit:
cvs rdiff -u -r1.43 -r1.44 src/sys/dev/dec/dz
Module Name:src
Committed By: andvar
Date: Thu Aug 24 14:21:40 UTC 2023
Modified Files:
src/sys/dev/dec: mcclock.c
Log Message:
s/MC_DFEAULTHZ/MC_DEFAULTHZ/ for alpha specific default rate definition.
To generate a diff of this commit:
cvs rdiff -u -r1.28 -r1.29 src/sys/
Module Name:src
Committed By: andvar
Date: Thu Aug 24 14:21:40 UTC 2023
Modified Files:
src/sys/dev/dec: mcclock.c
Log Message:
s/MC_DFEAULTHZ/MC_DEFAULTHZ/ for alpha specific default rate definition.
To generate a diff of this commit:
cvs rdiff -u -r1.28 -r1.29 src/sys/
Module Name:src
Committed By: andvar
Date: Sat Aug 19 19:21:34 UTC 2023
Modified Files:
src/sys/dev/dec: files.dec
Log Message:
remove likely accidental part of the comment.
To generate a diff of this commit:
cvs rdiff -u -r1.9 -r1.10 src/sys/dev/dec/files.dec
Please no
Module Name:src
Committed By: andvar
Date: Sat Aug 19 19:21:34 UTC 2023
Modified Files:
src/sys/dev/dec: files.dec
Log Message:
remove likely accidental part of the comment.
To generate a diff of this commit:
cvs rdiff -u -r1.9 -r1.10 src/sys/dev/dec/files.dec
Please no
Module Name:src
Committed By: riastradh
Date: Wed Oct 26 23:44:36 UTC 2022
Modified Files:
src/sys/dev/dec: dz.c
Log Message:
vax/dz(4): Convert to ttylock/ttyunlock.
To generate a diff of this commit:
cvs rdiff -u -r1.42 -r1.43 src/sys/dev/dec/dz.c
Please note that dif
Module Name:src
Committed By: riastradh
Date: Wed Oct 26 23:44:36 UTC 2022
Modified Files:
src/sys/dev/dec: dz.c
Log Message:
vax/dz(4): Convert to ttylock/ttyunlock.
To generate a diff of this commit:
cvs rdiff -u -r1.42 -r1.43 src/sys/dev/dec/dz.c
Please note that dif
Christoph Egger writes:
> Izumi Tsutsui wrote:
>>> Now, of course, that doesn't come as a surprise. Some people just never
>>> learn or listen. Or apologise.
>>
>> Honestly, I'd like to see proper fixes for output of
>> "grep -r 'memcpy( ' sys/arch" ,
>> before another set of mechanical change
I wrote:
> > Maybe ahc(4) was the only one that was broken. The point is that you
> > could have found this by comparing the object files.
>
> Although ahc(4) has many quirks (to share sources among *BSD/Linux),
> only aic7xxx_osm.c belongs to ahc(4) and it doesn't have any bad cast,
> per output
> > Honestly, I'd like to see proper fixes for output of
> > "grep -r 'memcpy( ' sys/arch" ,
> > before another set of mechanical changes.
>
> I broke it, so I will fix it.
> Do you want to review the patch ?
Well, it isn't functional changes at all.
Can you check it yourself before calling for r
Izumi Tsutsui wrote:
>> Now, of course, that doesn't come as a surprise. Some people just never
>> learn or listen. Or apologise.
>
> Honestly, I'd like to see proper fixes for output of
> "grep -r 'memcpy( ' sys/arch" ,
> before another set of mechanical changes.
I broke it, so I will fix it.
> Now, of course, that doesn't come as a surprise. Some people just never
> learn or listen. Or apologise.
Honestly, I'd like to see proper fixes for output of
"grep -r 'memcpy( ' sys/arch" ,
before another set of mechanical changes.
---
Izumi Tsutsui
> Maybe ahc(4) was the only one that was broken. The point is that you
> could have found this by comparing the object files.
Although ahc(4) has many quirks (to share sources among *BSD/Linux),
only aic7xxx_osm.c belongs to ahc(4) and it doesn't have any bad cast,
per output of grep adapt_dev sys
On Tue, May 12, 2009 at 05:15:05PM +0100, Robert Swindells wrote:
>
> Christoph Egger wrote:
> >> Valeriy E. Ushakov wrote:
> >> >On Tue, May 12, 2009 at 14:18:16 +, Christoph Egger wrote:
> >>
> >> >> struct device * -> device_t, no functional changes intended.
> >>
> >> >Why don't you cmp(
Robert Swindells wrote:
> Christoph Egger wrote:
>>> Valeriy E. Ushakov wrote:
On Tue, May 12, 2009 at 14:18:16 +, Christoph Egger wrote:
> struct device * -> device_t, no functional changes intended.
Why don't you cmp(1) the objects before and after to verify that?
"Same obj
Christoph Egger wrote:
>> Valeriy E. Ushakov wrote:
>> >On Tue, May 12, 2009 at 14:18:16 +, Christoph Egger wrote:
>>
>> >> struct device * -> device_t, no functional changes intended.
>>
>> >Why don't you cmp(1) the objects before and after to verify that?
>> >"Same object code generated" i
> Do a search in sys/dev/ic for 'adapt_dev', any driver that casts this
> to a softc instead of calling device_private() will crash.
struct device * and device_t are identical, so they won't crash
unless softc will actuall be split from device_t.
But I don't see benefits by mechanical changes aga
>
> Valeriy E. Ushakov wrote:
> >On Tue, May 12, 2009 at 14:18:16 +, Christoph Egger wrote:
>
> >> struct device * -> device_t, no functional changes intended.
>
> >Why don't you cmp(1) the objects before and after to verify that?
> >"Same object code generated" is, unlike intentions, somet
On Tue, May 12, 2009 at 04:24:07PM +0100, Robert Swindells wrote:
>
> Valeriy E. Ushakov wrote:
> >On Tue, May 12, 2009 at 14:18:16 +, Christoph Egger wrote:
>
> >> struct device * -> device_t, no functional changes intended.
>
> >Why don't you cmp(1) the objects before and after to verify t
Valeriy E. Ushakov wrote:
>On Tue, May 12, 2009 at 14:18:16 +, Christoph Egger wrote:
>> struct device * -> device_t, no functional changes intended.
>Why don't you cmp(1) the objects before and after to verify that?
>"Same object code generated" is, unlike intentions, something that can
>be
On Tue, May 12, 2009 at 14:18:16 +, Christoph Egger wrote:
> struct device * -> device_t, no functional changes intended.
Why don't you cmp(1) the objects before and after to verify that?
"Same object code generated" is, unlike intentions, something that can
be verified.
SY, Uwe
--
u...@std
30 matches
Mail list logo
