re: CVS commit: [riastradh-drm2] src/sys

[matthew green]

> Module Name:  src
> Committed By: riastradh
> Date: Wed Jan 29 19:47:38 UTC 2014
> 
> Modified Files:
>   src/sys/conf [riastradh-drm2]: files
>   src/sys/dev/pci [riastradh-drm2]: files.pci
>   src/sys/dev/wsfb [riastradh-drm2]: files.wsfb
>   src/sys/external/bsd/drm2/conf [riastradh-drm2]: files.drm2
>   src/sys/external/bsd/drm2/drm [riastradh-drm2]: drm_drv.c drm_module.c
>   drm_vm.c
>   src/sys/external/bsd/drm2/i915drm [riastradh-drm2]: i915_module.c
>   i915_pci.c
>   src/sys/external/bsd/drm2/include/linux [riastradh-drm2]: kgdb.h
>   src/sys/modules/drm2 [riastradh-drm2]: Makefile drm.ioconf
>   src/sys/modules/i915drm2 [riastradh-drm2]: Makefile i915drm.ioconf
> 
> Log Message:
> First draft of in-kernel drm2 attachment.
> 
> The drm2 `drm' device is now called `drmkms' (likewise `i915drmkms',
> &c.) so that it can coexist with the old drm code to reduce diffs
> from HEAD.  (Can't call a device `drm2'.)

there's probably a way to do this -- see how the current drm code
used to co-exist with the previous drm code (from sys/dev/drm).

you couldn't build them into the same kernel, but they were able
to share the name 'drm' and the major number.


.mrg.

re: CVS commit: [riastradh-drm2] src/sys/external/bsd/drm2/i915drm

[matthew green]

> Module Name:  src
> Committed By: riastradh
> Date: Wed Jan 29 19:47:09 UTC 2014
> 
> Modified Files:
>   src/sys/external/bsd/drm2/i915drm [riastradh-drm2]: i915_pci.c
> 
> Log Message:
> Defer i915drm_attach_framebuffer until interrupts are running.
> 
> The i915 code initialization relies on counting hardclock ticks for a
> delay (ugh).
> 
> Not an issue for modules, but it will matter when we build drm2 into
> the kernel proper.

not sure why this is a problem generally.  there have been
defer for interrupts primatives in our kernel for almost
2 deacdes now.


.mrg.

re: CVS commit: src/sys/arch/i386/include

[matthew green]

> In article <20140128065536.gg1...@apb-laptoy.apb.alt.za>,
> Alan Barrett   wrote:
> >On Mon, 27 Jan 2014, Christos Zoulas wrote:
> >>Modified Files:
> >>src/sys/arch/i386/include: vmparam.h
> >>
> >>Log Message:
> >>Cut down MAXDSIZE from 3G to 2.5G otherwise bottomup allocation ends up
> >>supplying an out of bounds hint for sigcode (c001e000 > bf00). Makes
> >>a.out binaries work again.
> >
> >Will this make malloc fail 0.5GB earlier than before?  The data 
> >size limits on i386 are already annoyingly small, and I would 
> >prefer not to make them smaller.  Please could you find a way to 
> >penalise only a.out programs.
> 
> I don't think it could allocate 3G before either. I think that the data
> segment would smash into the stack then. I can test though to verify.

it probably doesn't matter since most of the memory you'll
end up using for a large process with be counted against
RLIMIT_AS not RLIMIT_DATA, with modern malloc(3).


.mrg.

Re: CVS commit: src/sys/arch/arm/include

[Matt Thomas]

On Jan 29, 2014, at 12:25 PM, Alan Barrett  wrote:

> On Wed, 29 Jan 2014, Matt Thomas wrote:
>> Modified Files:
>>  src/sys/arch/arm/include: int_fmtio.h int_mwgwtypes.h
>> 
>> Log Message:
>> Make {,u}int{8,16,32} be of type int.
> 
> I think you mean:
> 
> Make {,u}int_fast{8,16,32} be of type int.

i do

Re: CVS commit: src/sys/arch/arm/include

[Alan Barrett]

On Wed, 29 Jan 2014, Matt Thomas wrote:

Modified Files:
src/sys/arch/arm/include: int_fmtio.h int_mwgwtypes.h

Log Message:
Make {,u}int{8,16,32} be of type int.


I think you mean:

Make {,u}int_fast{8,16,32} be of type int.

--apb (Alan Barrett)