* /dev/mem and xlate_dev_mem_ptr*()
@ 2007-01-27 12:49 Jimi Xenidis
2007-01-27 13:13 ` Keir Fraser
0 siblings, 1 reply; 3+ messages in thread
From: Jimi Xenidis @ 2007-01-27 12:49 UTC (permalink / raw)
To: xen-devel; +Cc: xen-ppc-devel
in the 2.6.18 linux of the sparse tree you have:
drivers/xen/char/mem.c using xlate_dev_mem_ptr as 2 args.
What is the story with this? has the interface changed from under you?
Why not invent a new interface that does not conflict, since this is
your code?
-JX
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: /dev/mem and xlate_dev_mem_ptr*()
2007-01-27 12:49 /dev/mem and xlate_dev_mem_ptr*() Jimi Xenidis
@ 2007-01-27 13:13 ` Keir Fraser
2007-01-27 13:16 ` Jimi Xenidis
0 siblings, 1 reply; 3+ messages in thread
From: Keir Fraser @ 2007-01-27 13:13 UTC (permalink / raw)
To: Jimi Xenidis, xen-devel; +Cc: xen-ppc-devel
On 27/1/07 12:49 pm, "Jimi Xenidis" <jimix@watson.ibm.com> wrote:
> in the 2.6.18 linux of the sparse tree you have:
> drivers/xen/char/mem.c using xlate_dev_mem_ptr as 2 args.
>
> What is the story with this? has the interface changed from under you?
> Why not invent a new interface that does not conflict, since this is
> your code?
The functions are used only by the /dev/mem driver so really they belong to
us, if you choose to build with our alternative driver. The original
interface is unimplementable over Xen (since we do not have 1:1 mappings of
everything). If those changes get merged upstream I would expect a size
parameter would get added to the function in upstream too.
-- Keir
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: /dev/mem and xlate_dev_mem_ptr*()
2007-01-27 13:13 ` Keir Fraser
@ 2007-01-27 13:16 ` Jimi Xenidis
0 siblings, 0 replies; 3+ messages in thread
From: Jimi Xenidis @ 2007-01-27 13:16 UTC (permalink / raw)
To: Keir Fraser; +Cc: xen-devel, xen-ppc-devel
On Jan 27, 2007, at 8:13 AM, Keir Fraser wrote:
> On 27/1/07 12:49 pm, "Jimi Xenidis" <jimix@watson.ibm.com> wrote:
>
>> in the 2.6.18 linux of the sparse tree you have:
>> drivers/xen/char/mem.c using xlate_dev_mem_ptr as 2 args.
>>
>> What is the story with this? has the interface changed from under
>> you?
>> Why not invent a new interface that does not conflict, since this is
>> your code?
>
> The functions are used only by the /dev/mem driver so really they
> belong to
> us, if you choose to build with our alternative driver. The original
> interface is unimplementable over Xen (since we do not have 1:1
> mappings of
> everything). If those changes get merged upstream I would expect a
> size
> parameter would get added to the function in upstream too.
Respectfully, my guess would be that the maintainers would ask that
"your" driver to not overload an existing interface and make your
own, I know the PPC maintainers would, especially since we all share
a single binary.
-JX
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2007-01-27 13:16 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2007-01-27 12:49 /dev/mem and xlate_dev_mem_ptr*() Jimi Xenidis
2007-01-27 13:13 ` Keir Fraser
2007-01-27 13:16 ` Jimi Xenidis
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.