On Sat, 10 Apr 2010, matthew green wrote:
would you try this variant? it handles the case where MEXTMALLOC()
would fail to allocate external storage, and seems to work on my
iwn(4). i'll commit this if you confirm it works.
*** if_iwn.c 5 Apr 2010 07:20:26
On Sat, Apr 03, 2010 at 01:16:46PM +1100, matthew green wrote:
I would like to add the MI function prototypes underneath the
#include:
#include machine/bus.h
/* MI function prototypes */
bus_space_tag_t bus_space_tag_create
On Sat, Apr 03, 2010 at 01:16:46PM +1100, matthew green wrote:
I would like to add the MI function prototypes underneath the
#include:
#include machine/bus.h
/* MI function prototypes */
bus_space_tag_t
(I'll learn TTE then reply again.)
for everyone:
TTE is sparc64 for PTE. translation table entry. defined in
sparc64/include/pte.h :-)
To manage dependency nicely.
When a module A dpend on B, you write define A: B, where B has to be
already define'ed in the current syntax. We're managing such
ordering by hand in sys/conf/files. By splitting files use
include, we don't need to manage such a mess by hand.
i don't understand why you think framebuffers are mapped uncacheable.
your proposal appears to provide no benefit for anything currently
supported, and i'm not sure why bus_space_physload() needs to be
in the bus_space domain, rather than plain UVM. your XIP use-case
may be valid -- i haven't
int prot is the device's characteristic. Audio mic devices would use
VM_PROT_READ. Framebuffers would use VM_PROT_WRITE. We need to introduce
BUS_SPACE_PROT_* symbols too.
i don't see why you think that reads from fb devices never occur.
i'm also unsure how audio devices matter
i don't see how changing the size of paddr_t affects userland except
for kvm and kvm is already special case and can/should be able to
handle it. sparc deals with things like this already.
.mrg.
1. The firmware is large, with about 60k. Does anybody have experience
with using a compressed firmware image in the driver, which is uncompressed
on the fly, while uploading it to the chip? How would I do that?
(This would probably make sense for most firmware, so a common
i like the look of this.
have you tested it on anything besides sparc64 yet?
.mrg.
On Sat, Jan 30, 2010 at 08:45:48PM +0100, Frank Wille wrote:
Therefore I would like to change ddb/db_write_cmd.c as in the following
patch:
[...]
Any objections? Do we absolutely need to print the old value here?
I think it's somewhat desirable to. Wouldn't it
another alternative would be to add a flag to write, eg write/n.
.mrg.
what is the purpose of this change?
struct lwp is approx 700-1000 bytes on our platforms.
that's a significant chunk to remove from kernel stacks isn't it?
.mrg.
Wondering: would it make sense for savecore to run asynchronously,
rather than waiting for it to complete before continuing with the rest
of system startup?
does this work for you:
echo savecore_flags='' /etc/rc.conf
?
traditionally savecore runs early before swapping starts...
401 - 414 of 414 matches
Mail list logo
