On Wed, Mar 24, 2010 at 03:06:08PM +0900, Masao Uebayashi wrote:
> void *bus_space_physload(bus_space_tag_t space, bus_addr_t addr,
> bus_size_t size);
This function should take the same arguments as bus_space_mmap(9). I've
added "int prot" and "int flags":
void *bus_spac
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 co
"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 f
On Tue, Mar 23, 2010 at 07:03:11PM -0700, Michael Graff wrote:
> It appears that this patch works. I believe the submitter was working
> on Ruby 1.9 on NetBSD, and ran into this (which I also did.)
>
> The supplied patch works on my netbsd-5 branch test box, and should also
> apply for current.
>
> I'd like to propose a new function in bus_space(9) API, bus_space_physload(9).
>
> void *bus_space_physload(bus_space_tag_t space, bus_addr_t addr,
> bus_size_t size);
>
> This function is provided for device drivers to register its linear memory
> region to be managed by VM. W
On Wed, Mar 24, 2010 at 04:53:07PM +1100, matthew green wrote:
>
> yeah.
>
> while i agree with joerg that these operations aren't well defined, we
> can do something a bit more sane like this patch.
>
> i think it's OK.
The behavior described in the PR sounds exactly like what should happen.
T
Hi!
Anyone can have a look at this and/or test it?
http://www.netbsd.org/~ahoka/patches/sys_modules_pad.tar.gz
This is my first try at making a module, so any comments
are welcomed. :-)
Cheers,
Adam
--
NetBSD - Simplicity is prerequisite for reliability
On Wed, Mar 24, 2010 at 07:56:27PM +1100, matthew green wrote:
>
> 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 domai
On Wed, Mar 24, 2010 at 09:15:53PM +0900, Izumi Tsutsui wrote:
> > I'd like to propose a new function in bus_space(9) API,
> > bus_space_physload(9).
> >
> > void *bus_space_physload(bus_space_tag_t space, bus_addr_t addr,
> > bus_size_t size);
> >
> > This function is provided for d
On Fri, Mar 12, 2010 at 4:31 AM, David Holland wrote:
> On Mon, Mar 08, 2010 at 06:33:04PM +0900, Masao Uebayashi wrote:
> > > Well, first of all nothing says you can't read the whole file before
> > > resolving dependencies; there's nothing inherently wrong with
> > >
> > > define foo: bar
>
On Mon, Mar 22, 2010 at 6:14 AM, Sverre Froyen wrote:
> On Sat March 20 2010 17:24:07 David Young wrote:
>> On Sat, Mar 20, 2010 at 09:43:21AM -0700, Matt Thomas wrote:
>> > On Mar 20, 2010, at 9:06 AM, Masao Uebayashi wrote:
>> > > On Sun, Mar 21, 2010 at 1:01 AM, Matt Thomas
> wrote:
>> > >> I'
2010/3/16 Wojciech A. Koszek :
> On Tue, Mar 16, 2010 at 06:55:36AM +0900, Masao Uebayashi wrote:
>> On Tue, Mar 16, 2010 at 1:57 AM, Eduardo Horvath wrote:
>> > On Sun, 14 Mar 2010, Wojciech A. Koszek wrote:
>> >
>> >> I was wondering how does Linux/Solaris kernel build system work in terms
>> >
2010/3/16 Wojciech A. Koszek :
> On Mon, Mar 15, 2010 at 11:50:09PM +0900, Masao Uebayashi wrote:
>> 2010/3/15 Wojciech A. Koszek :
>> > device X
>> >
>> > builds device X staticly into the kernel (and maybe does something
>> > device-specific), while:
>> >
>> > module X
>> >
>> > O
On Mar 24, 2010, at 8:07 AM, Masao Uebayashi wrote:
> On Wed, Mar 24, 2010 at 09:15:53PM +0900, Izumi Tsutsui wrote:
>>> I'd like to propose a new function in bus_space(9) API,
>>> bus_space_physload(9).
>>>
>>> void *bus_space_physload(bus_space_tag_t space, bus_addr_t addr,
>>> bu
On Thu, Mar 25, 2010 at 01:16:02AM +0900, Masao Uebayashi wrote:
> On Mon, Mar 22, 2010 at 6:14 AM, Sverre Froyen wrote:
> > Could this be resolved by adding a "get label" ioctl that could be used on
> > any
> > device? ?It might return a descriptive string from the device driver /
> > config
>
On Wed, Mar 24, 2010 at 05:09:23PM +0900, Masao Uebayashi wrote:
> On Wed, Mar 24, 2010 at 03:06:08PM +0900, Masao Uebayashi wrote:
> > void *bus_space_physload(bus_space_tag_t space, bus_addr_t addr,
> > bus_size_t size);
>
> This function should take the same arguments as bus_space_m
>>> Could this be resolved by adding a "get label" ioctl that could be
>>> used on any device?
>> That's part of the plan of "my devfs".
> yuck.
Agreed. For one thing, you can't ioctl anything until you open it,
which is a nontrivial operation for many devices - and closing it when
you're done is
On 3/24/10 3:09 AM, Andrew Doran wrote:
The comment that pthread_* functions cannot safely be used in the forked
child is not QUITE what I understand to be what POSIX has in mind. They
say only one thread is running (that is, the child's MAIN thread).
Creating another thread afterwards should be
On Wed, Mar 24, 2010 at 03:09:19PM -0700, Michael Graff wrote:
> The comment that pthread_* functions cannot safely be used in the forked
> child is not QUITE what I understand to be what POSIX has in mind.
To quote the SUSv3:
***cut**
A process shall be created with a single thread. If a multi-t
On 3/24/10 3:32 PM, Joerg Sonnenberger wrote:
>> Consider the method to become a daemon, you fork() then let the child
>> continue. Surely we're not saying you cannot use pthread_create() there...
>
> You are confusing something here. The constraints apply to
> multi-threaded programs. Most daemo
On Wed, Mar 24, 2010 at 10:35:20AM -0700, Matt Thomas wrote:
> > bus_space_physload(9) is to replace bus_space_mmap(9).
>
> Then where is bus_space_unphysload? You have to be able to undo it when
> you start talking about devices.
You're right, bus_space_unphysload(9) (or *_physunload?) is neede
On Wed, Mar 24, 2010 at 01:07:15PM -0500, David Young wrote:
> Can it be implemented like this?
>
> void *
> bus_space_physload(bus_space_tag_t bst, bus_addr_t addr, bus_size_t size,
> vm_prot_t prot, int flags)
> {
> bus_space_handle_t bsh;
> void *p;
> int rc;
>
> rc
On Thu, Mar 25, 2010 at 11:43:52AM +0900, Masao Uebayashi wrote:
> void *
> bus_space_physload(bus_space_tag_t t, bus_addr_t addr, bus_size_t size,
> int prot, int flags)
> {
> const bus_addr_t busp = addr;
> const bus_addr_t busq = addr + siz
On Thu, Mar 25, 2010 at 01:14:51AM +0900, Masao Uebayashi wrote:
> > ?> > (Besides, it's not necessarily as flat as all that, either.)
> > ?>
> > ?> It's necessary to be flat to be modular.
> >
> > Mm... not strictly. That's only true when there are diamonds in the
> > dependency graph; other
On Fri, Mar 19, 2010 at 02:49:37PM +, Andrew Doran wrote:
> > I *do* think it's a useful datapoint to note that sun2, pmax, algor, etc.
> > are never, ever downloaded any more.
>
> Right, and these dead ports must be euthanized. The mountain of
> unused device drivers and core kernel cod
On Thu, Mar 25, 2010 at 12:18 PM, David Holland
wrote:
> On Thu, Mar 25, 2010 at 01:14:51AM +0900, Masao Uebayashi wrote:
> > > ?> > (Besides, it's not necessarily as flat as all that, either.)
> > > ?>
> > > ?> It's necessary to be flat to be modular.
> > >
> > > Mm... not strictly. That's o
On Wed, Mar 24, 2010 at 05:59:50PM -0700, Michael Graff wrote:
> Ruby seems to be executing some tests in a forked multithreaded
> environment. I have no reason to believe they are doing anything that
> isn't prepared to handle a totally new, blank pthread-allowing environment.
The point is that
Another question is, do we want to register device memory as part of usual
memory? For example OpenBSD seems to be trying to use framebuffer's memory
for mbufs.
It's possible if we prepare the relevant interface and call uvm_page_physload(9)
instead of uvm_page_physload_device(9). Maybe worth pr
28 matches
Mail list logo
