Re: [PATCH] Fix build warning of the defconfigs
On Thu, 2011-06-02 at 00:29 +0800, Wanlong Gao wrote: > RTC_CLASS is changed to bool. > So value 'm' is invalid. > > Signed-off-by: Wanlong Gao > arch/avr32/configs/atngw100_mrmt_defconfig |2 +- > For the AVR32 related changes. Acked-by: Hans-Christian Egtvedt -- Hans-Christian Egtvedt ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [RFC][PATCH] powerpc: Use the #address-cells information to parse memory/reg
On 05/30/11 12:00, Suzuki Poulose wrote:
Use the #address-cells, #size-cells information to parse the memory/reg info
from device tree.
The format of memory/reg is based on the #address-cells,#size-cells. Currently,
the kexec-tools doesn't use the above values in parsing the memory/reg values.
Hence the kexec cannot handle cases where #address-cells, #size-cells are
different, (for e.g, PPC440X ).
This patch introduces a read_memory_region_limits(), which parses the
memory/reg contents based on the values of #address-cells and #size-cells.
Changed the add_usable_mem_property() to accept FILE* fp instead of int fd,
as most of the other users of read_memory_region_limits() deals with FILE*.
Signed-off-by: Suzuki K. Poulose
Could you please let me know your thoughts/comments about this patch ?
Thanks
Suzuki
---
kexec/arch/ppc/crashdump-powerpc.c | 23 --
kexec/arch/ppc/fs2dt.c | 31 ++--
kexec/arch/ppc/kexec-ppc.c | 136 ++---
kexec/arch/ppc/kexec-ppc.h | 6 +
4 files changed, 118 insertions(+), 78 deletions(-)
Index: kexec-tools-2.0.4/kexec/arch/ppc/kexec-ppc.c
===
--- kexec-tools-2.0.4.orig/kexec/arch/ppc/kexec-ppc.c
+++ kexec-tools-2.0.4/kexec/arch/ppc/kexec-ppc.c
@@ -26,6 +26,7 @@
#include "config.h"
+unsigned long dt_address_cells = 0, dt_size_cells = 0;
uint64_t rmo_top;
unsigned long long crash_base = 0, crash_size = 0;
unsigned long long initrd_base = 0, initrd_size = 0;
@@ -34,6 +35,92 @@ unsigned int rtas_base, rtas_size;
int max_memory_ranges;
const char *ramdisk;
+/*
+ * Reads the #address-cells and #size-cells on this platform.
+ * This is used to parse the memory/reg info from the device-tree
+ */
+int init_memory_region_info()
+{
+ size_t res = 0;
+ FILE *fp;
+ char *file;
+
+ file = "/proc/device-tree/#address-cells";
+ fp = fopen(file, "r");
+ if (!fp) {
+ fprintf(stderr,"Unable to open %s\n", file);
+ return -1;
+ }
+
+ res = fread(&dt_address_cells,sizeof(unsigned long),1,fp);
+ if (res != 1) {
+ fprintf(stderr,"Error reading %s\n", file);
+ return -1;
+ }
+ fclose(fp);
+ dt_address_cells *= sizeof(unsigned long);
+
+ file = "/proc/device-tree/#size-cells";
+ fp = fopen(file, "r");
+ if (!fp) {
+ fprintf(stderr,"Unable to open %s\n", file);
+ return -1;
+ }
+
+ res = fread(&dt_size_cells,sizeof(unsigned long),1,fp);
+ if (res != 1) {
+ fprintf(stderr,"Error reading %s\n", file);
+ return -1;
+ }
+ fclose(fp);
+ dt_size_cells *= sizeof(unsigned long);
+
+ return 0;
+}
+
+#define MAXBYTES 128
+/*
+ * Reads the memory region info from the device-tree node pointed
+ * by @fp and fills the *start, *end with the boundaries of the region
+ */
+int read_memory_region_limits(FILE* fp, unsigned long long *start,
+ unsigned long long *end)
+{
+ char buf[MAXBYTES];
+ unsigned long *p;
+ unsigned long nbytes = dt_address_cells + dt_size_cells;
+
+ if (fread(buf, 1, MAXBYTES, fp) != nbytes) {
+ fprintf(stderr, "Error reading the memory region info\n");
+ return -1;
+ }
+
+ p = (unsigned long*)buf;
+ if (dt_address_cells == sizeof(unsigned long)) {
+ *start = p[0];
+ p++;
+ } else if (dt_address_cells == sizeof(unsigned long long)) {
+ *start = ((unsigned long long *)p)[0];
+ p = (unsigned long long *)p + 1;
+ } else {
+ fprintf(stderr,"Unsupported value for #address-cells : %ld\n",
+ dt_address_cells);
+ return -1;
+ }
+
+ if (dt_size_cells == sizeof(unsigned long))
+ *end = *start + p[0];
+ else if (dt_size_cells == sizeof(unsigned long long))
+ *end = *start + ((unsigned long long *)p)[0];
+ else {
+ fprintf(stderr,"Unsupported value for #size-cells : %ld\n",
+ dt_size_cells);
+ return -1;
+ }
+
+ return 0;
+}
+
void arch_reuse_initrd(void)
{
reuse_initrd = 1;
@@ -182,9 +269,6 @@ static int sort_base_ranges(void)
return 0;
}
-
-#define MAXBYTES 128
-
static int realloc_memory_ranges(void)
{
size_t memory_range_len;
@@ -248,6 +332,8 @@ static int get_base_ranges(void)
return -1;
}
while ((mentry = readdir(dmem)) != NULL) {
+ unsigned long long start, end;
+
if (strcmp(mentry->d_name, "reg"))
continue;
strcat(fname, "/reg");
@@ -257,8 +343,7 @@ static int get_base_ranges(void)
closedir(dir);
return -1;
}
- if ((n = fread(buf, 1, MAXBYTES, file)) < 0) {
- perror(fname);
+ if (read_memory_region_limits(file, &start, &end) != 0) {
fclose(file);
closedir(dmem);
closedir(dir);
@@ -271,24 +356,8 @@ static int get_base_ranges(void)
}
}
- if (n == sizeof(uint32_t) * 2) {
- base_memory_range[local_memory_ranges].start =
- ((uint32_t *)buf)[0];
- base_memory_range[local_memory_ranges].end =
- base_memory_range[local_memory_ranges].start +
- ((uint32_t *)buf)[1];
- }
- else if (n == sizeof(uint64_t) * 2) {
- base_memory_range[local_memory_ranges].start =
- ((uint64_t *)buf)[0];
- base_memory_range[local_memory_ranges].end =
- base_memory_range[local_memory_ranges].start +
- ((uint64_t *)buf)[1];
- }
- else {
- fprintf(stderr, "Mem node has invalid size: %d\n", n);
- return -1;
- }
+ base_memory_ran
Re: [RFC][PATCH] powerpc: Use the #address-cells information to parse memory/reg
Suzuki Poulose wrote:
Could you please let me know your thoughts/comments about this patch ?
I'm mostly fine with it.
Maaxim copied fs2dt.c from ppc64 to ppc. So I guess ppc64 has the same
problem. ARM and MIPS is soon having DT support and kexec is probably also
on their list so I would hate to see them to either copy the DT parsing
file or having their own implementation.
Maybe we should try to use libfdt for dt parsing. It has /proc import
support so it should be fine for our needs. It is already in tree and used
by ppc32 if a basic dtb is specified. I'm not sure if the /proc interface
is part of dtc or libfdt.
I'm not saying this has to be done now but maybe later before ARM and/or
MIPS comes along needs something similar for their needs. If the libfdt is
too complex for sucking in the dtb from /proc then maybe something else
that generic and can be shared between booth ppc architectures and the
other ones.
Thanks
Suzuki
Index: kexec-tools-2.0.4/kexec/arch/ppc/kexec-ppc.c
===
--- kexec-tools-2.0.4.orig/kexec/arch/ppc/kexec-ppc.c
+++ kexec-tools-2.0.4/kexec/arch/ppc/kexec-ppc.c
@@ -34,6 +35,92 @@ unsigned int rtas_base, rtas_size;
int max_memory_ranges;
const char *ramdisk;
+/*
+ * Reads the #address-cells and #size-cells on this platform.
+ * This is used to parse the memory/reg info from the device-tree
+ */
+int init_memory_region_info()
+{
+ size_t res = 0;
+ FILE *fp;
+ char *file;
+
+ file = "/proc/device-tree/#address-cells";
+ fp = fopen(file, "r");
+ if (!fp) {
+ fprintf(stderr,"Unable to open %s\n", file);
+ return -1;
+ }
+
+ res = fread(&dt_address_cells,sizeof(unsigned long),1,fp);
+ if (res != 1) {
+ fprintf(stderr,"Error reading %s\n", file);
+ return -1;
+ }
+ fclose(fp);
+ dt_address_cells *= sizeof(unsigned long);
This should be sizeof(unsigned int). I know we on 32bit.
+ file = "/proc/device-tree/#size-cells";
+ fp = fopen(file, "r");
+ if (!fp) {
+ fprintf(stderr,"Unable to open %s\n", file);
+ return -1;
+ }
+
+ res = fread(&dt_size_cells,sizeof(unsigned long),1,fp);
+ if (res != 1) {
+ fprintf(stderr,"Error reading %s\n", file);
+ return -1;
+ }
+ fclose(fp);
+ dt_size_cells *= sizeof(unsigned long);
same here.
+
+ return 0;
+}
+
Sebastian
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [RFC][PATCH] powerpc: Use the #address-cells information to parsememory/reg
> > Changed the add_usable_mem_property() to accept FILE* fp instead of int fd, > > as most of the other users of read_memory_region_limits() deals with FILE*. > > > > Signed-off-by: Suzuki K. Poulose > > Could you please let me know your thoughts/comments about this patch ? Is the change to use 'FILE *' actually progress? I'd have thought that the randomly aligned read/lseek system calls that this allows to happen are not desirable for anything that isn't a true file. I'd also suggest that the sizeof's should be applied to the actual type of the variable being read/written, not arbitrarily 'long' or 'int', and this probably ought to be some fixed size type. David ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [RFC][PATCH] powerpc: Use the #address-cells information to parse memory/reg
On 06/06/11 14:21, Sebastian Andrzej Siewior wrote:
Suzuki Poulose wrote:
Could you please let me know your thoughts/comments about this patch ?
I'm mostly fine with it.
Maaxim copied fs2dt.c from ppc64 to ppc. So I guess ppc64 has the same
problem.
Yes, you are right. Porting this patch over to ppc64 is in my TODO list.
ARM and MIPS is soon having DT support and kexec is probably also
on their list so I would hate to see them to either copy the DT parsing
file or having their own implementation.
Maybe we should try to use libfdt for dt parsing. It has /proc import
support so it should be fine for our needs. It is already in tree and used
by ppc32 if a basic dtb is specified. I'm not sure if the /proc interface
is part of dtc or libfdt.
I'm not saying this has to be done now but maybe later before ARM and/or
MIPS comes along needs something similar for their needs. If the libfdt is
too complex for sucking in the dtb from /proc then maybe something else
that generic and can be shared between booth ppc architectures and the
other ones.
OK
Index: kexec-tools-2.0.4/kexec/arch/ppc/kexec-ppc.c
===
--- kexec-tools-2.0.4.orig/kexec/arch/ppc/kexec-ppc.c
+++ kexec-tools-2.0.4/kexec/arch/ppc/kexec-ppc.c
@@ -34,6 +35,92 @@ unsigned int rtas_base, rtas_size;
int max_memory_ranges;
const char *ramdisk;
+/*
+ * Reads the #address-cells and #size-cells on this platform.
+ * This is used to parse the memory/reg info from the device-tree
+ */
+int init_memory_region_info()
+{
+ size_t res = 0;
+ FILE *fp;
+ char *file;
+
+ file = "/proc/device-tree/#address-cells";
+ fp = fopen(file, "r");
+ if (!fp) {
+ fprintf(stderr,"Unable to open %s\n", file);
+ return -1;
+ }
+
+ res = fread(&dt_address_cells,sizeof(unsigned long),1,fp);
+ if (res != 1) {
+ fprintf(stderr,"Error reading %s\n", file);
+ return -1;
+ }
+ fclose(fp);
+ dt_address_cells *= sizeof(unsigned long);
This should be sizeof(unsigned int). I know we on 32bit.
OK. I was using (unsigned long) to get the word size on the machine. Given
this code is duplicated in ppc64, thought of having a generic code which works
fine for all ppcXX. As you mentioned, if we go about moving to a single copy of
fdt code, using long would help us.
+ file = "/proc/device-tree/#size-cells";
+ fp = fopen(file, "r");
+ if (!fp) {
+ fprintf(stderr,"Unable to open %s\n", file);
+ return -1;
+ }
+
+ res = fread(&dt_size_cells,sizeof(unsigned long),1,fp);
+ if (res != 1) {
+ fprintf(stderr,"Error reading %s\n", file);
+ return -1;
+ }
+ fclose(fp);
+ dt_size_cells *= sizeof(unsigned long);
same here.
Thanks
Suzuki
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [RFC][PATCH] powerpc: Use the #address-cells information to parsememory/reg
On 06/06/11 14:30, David Laight wrote: Changed the add_usable_mem_property() to accept FILE* fp instead of int fd, as most of the other users of read_memory_region_limits() deals with FILE*. Signed-off-by: Suzuki K. Poulose Could you please let me know your thoughts/comments about this patch ? Is the change to use 'FILE *' actually progress? I'd have thought that the randomly aligned read/lseek system calls that this allows to happen are not desirable for anything that isn't a true file. I will revert the other users back to 'fd' I'd also suggest that the sizeof's should be applied to the actual type of the variable being read/written, not arbitrarily 'long' or 'int', and this probably ought to be some fixed size type. I have used 'unsigned long'(for word sized values) or 'unsigned long long' (for double words) just to make sure we get the right values. Is this OK ? Thanks Suzuki ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 7/7] [v2] drivers/misc: introduce Freescale hypervisor management driver
On Friday 03 June 2011, Timur Tabi wrote: > Arnd Bergmann wrote: > >> > I don't think it's correct to think of a hypervisor as firmware, so I > >> > don't > >> > think drivers/firmware is better. > >> > > >> > I'm not sure that creating virt/fsl and putting the driver in there is a > >> > good > >> > idea, because it will be the only driver in that directory. Unlike KVM, > >> > this > >> > driver is just a collection of front-ends to our hypervisor API. The > >> > actual > >> > hypervisor is completely separate. That's why I put it in drivers/misc, > >> > because > >> > it's just a single driver with a miscellaneous collection of interfaces. > > > Ok, fair enough. If nobody has a strong preference any other way, just make > > it > > drivers/firmware then. > > Did you mean to say drivers/misc? Sorry, I misread your first sentence above. I thought you said that you prefer drivers/firmware over virt/fsl. drivers/misc is definitely the wrong place for this, please choose a better one. Maybe drivers/virt/ ? Arnd ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 7/7] [v2] drivers/misc: introduce Freescale hypervisor management driver
Arnd Bergmann wrote: > Sorry, I misread your first sentence above. I thought you said that you prefer > drivers/firmware over virt/fsl. drivers/misc is definitely the wrong > place for this, please choose a better one. Maybe drivers/virt/ ? I'll be more than happy to go with the consensus, but I don't think it makes sense to create a new directory just for this one, limited-use driver. You're the only person who's complained about drivers/misc. I'm pretty sure that if I put it in drivers/virt, I'll get more complaints. I still don't understand what's wrong with drivers/misc, especially since my driver registers as a "misc" driver. -- Timur Tabi Linux kernel developer at Freescale ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 7/7] [v2] drivers/misc: introduce Freescale hypervisor management driver
On Friday 03 June 2011, Scott Wood wrote: > On Fri, 3 Jun 2011 17:28:43 +0200 > Arnd Bergmann wrote: > > > On Thursday 02 June 2011, Scott Wood wrote: > > > I wanted to have the hypervisor take an update dtb (we already have > > > special > > > meta-properties for things like deletion as part of the hv config > > > mechanism). But others on the project wanted to keep it simple, and so > > > get/set property it was. :-/ > > > > > > It's unlikely to change at this point without a real need. > > > > > > As for a filesystem interface, it's not a good match either. > > > You can't iterate over anything to read out the full tree from the hv. > > > > kexec iterates over /proc/device-tree to create a dts blob. > > That's irrelevant, because we're not talking about that device tree. We're > talking about the device tree of another hypervisor guest. I understand that it's a different device tree. That doesn't mean we can't use the same tools. > > > You can't delete anything. > > > > rm, rmdir > > > > > You can't create empty nodes. > > > > mkdir > > I know how to operate a filesystem. You can't do these operations *on > another guest's device tree through the hv interface*. Why not? From a device driver perspective, it's not much of a difference whether you export a device (or hypervisor, firmware, ...) setting as an ioctl or an inode operation. > > > There would still be other ioctls needed for starting/stopping the > > > partition, etc. > > > > Right, although you could model them as a file interface as well. > > KVMfs is one example doing that. > > And what would be the benefit of this major restructuring and added > complexity? I think it would be a slightly better abstraction, and the complexity is not as big as you make it sound. I'm mainly countering your statement that it would be a bad interface or that would not possible to do. I'm not that opposed to having an ioctl interface for your hypervisor interface, but I am opposed to making design choices based on a bad representations of facts or not having considered the options that other people suggest. Arnd ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 7/7] [v2] drivers/misc: introduce Freescale hypervisor management driver
On Monday 06 June 2011, Timur Tabi wrote: > Arnd Bergmann wrote: > > Sorry, I misread your first sentence above. I thought you said that you > > prefer > > drivers/firmware over virt/fsl. drivers/misc is definitely the wrong > > place for this, please choose a better one. Maybe drivers/virt/ ? > > I'll be more than happy to go with the consensus, but I don't think it makes > sense to create a new directory just for this one, limited-use driver. You're > the only person who's complained about drivers/misc. I'm pretty sure that if > I > put it in drivers/virt, I'll get more complaints. > > I still don't understand what's wrong with drivers/misc, especially since my > driver registers as a "misc" driver. I basically think that drivers/misc is wrong for most of the stuff that is already in there, either because the drivers actually fit into a subsystem together with other drivers or because they contain rather horrible code. The idea that drivers using misc_register belong into drivers/misc is a common misconception. Traditionally they go to drivers/char, which would still be a better choice, and most "misc" drivers are actually part of a proper subsystem, while most drivers in drivers/misc don't have a character device interface. When we talked about the situation of drivers/misc and drivers/char at one of the recent conferences, a broad consensus was that they are in need of a maintainer, which I foolishly signed up for. Deepak wanted to send an update to the MAINTAINERS file for this (I guess I can do that too, since he must have forgotten about it), but the main idea is that I'm there to say no to any driver that someone tries to add there, unless there are really good reasons why it is actually a good place to live for that driver. Arnd ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 7/7] [v2] drivers/misc: introduce Freescale hypervisor management driver
Arnd Bergmann wrote: > When we talked about the situation of drivers/misc and drivers/char at > one of the recent conferences, a broad consensus was that they are in > need of a maintainer, which I foolishly signed up for. Deepak wanted > to send an update to the MAINTAINERS file for this (I guess I can do > that too, since he must have forgotten about it), but the main idea is > that I'm there to say no to any driver that someone tries to add there, > unless there are really good reasons why it is actually a good place > to live for that driver. Can you give me an example of a driver that *does* belong in drivers/misc? Frankly, I just don't see what's wrong with a repository of various drivers that don't really belong anywhere else. And what about my concern that my driver will be the only one in drivers/virt? -- Timur Tabi Linux kernel developer at Freescale ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 7/7] [v2] drivers/misc: introduce Freescale hypervisor management driver
On Monday 06 June 2011, Timur Tabi wrote: > Arnd Bergmann wrote: > > When we talked about the situation of drivers/misc and drivers/char at > > one of the recent conferences, a broad consensus was that they are in > > need of a maintainer, which I foolishly signed up for. Deepak wanted > > to send an update to the MAINTAINERS file for this (I guess I can do > > that too, since he must have forgotten about it), but the main idea is > > that I'm there to say no to any driver that someone tries to add there, > > unless there are really good reasons why it is actually a good place > > to live for that driver. > > Can you give me an example of a driver that does belong in drivers/misc? Not really. > Frankly, I just don't see what's wrong with a repository of various drivers > that > don't really belong anywhere else. The main problem is that for the most part it's a pile of crap that nobody wants to look at, so drivers getting added there see basically no real review. > And what about my concern that my driver will be the only one in drivers/virt? I have no doubt that more of these will come. Chris Metcalf is currently looking for a home for his tilera hypervisor drivers, and we have the microsoft hyperv drivers in drivers/staging, so they will hopefully move to a proper place later. We also have similar drivers in other places, e.g. drivers/ps3/ps3-sys-manager.c, drivers/s390/char/vmcp.c or parts of drivers/xen. Arnd ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 7/7] [v2] drivers/misc: introduce Freescale hypervisor management driver
Arnd Bergmann wrote: > I have no doubt that more of these will come. Chris Metcalf is currently > looking for a home for his tilera hypervisor drivers, and we have the > microsoft hyperv drivers in drivers/staging, so they will hopefully > move to a proper place later. We also have similar drivers in other > places, e.g. drivers/ps3/ps3-sys-manager.c, drivers/s390/char/vmcp.c > or parts of drivers/xen. Alright, drivers/virt it is. I'll post a v4 once everyone else has had a chance to comment on v3. -- Timur Tabi Linux kernel developer at Freescale ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 7/7] [v2] drivers/misc: introduce Freescale hypervisor management driver
On Mon, 6 Jun 2011 17:53:09 +0200 Arnd Bergmann wrote: > On Friday 03 June 2011, Scott Wood wrote: > > On Fri, 3 Jun 2011 17:28:43 +0200 > > Arnd Bergmann wrote: > > > > > On Thursday 02 June 2011, Scott Wood wrote: > > > > I wanted to have the hypervisor take an update dtb (we already have > > > > special > > > > meta-properties for things like deletion as part of the hv config > > > > mechanism). But others on the project wanted to keep it simple, and so > > > > get/set property it was. :-/ > > > > > > > > It's unlikely to change at this point without a real need. > > > > > > > > As for a filesystem interface, it's not a good match either. > > > > You can't iterate over anything to read out the full tree from the hv. > > > > > > kexec iterates over /proc/device-tree to create a dts blob. > > > > That's irrelevant, because we're not talking about that device tree. We're > > talking about the device tree of another hypervisor guest. > > I understand that it's a different device tree. That doesn't mean we > can't use the same tools. The kernel does not have the same sort of access to this tree. > > > > You can't delete anything. > > > > > > rm, rmdir > > > > > > > You can't create empty nodes. > > > > > > mkdir > > > > I know how to operate a filesystem. You can't do these operations *on > > another guest's device tree through the hv interface*. > > Why not? Because the hypervisor does not support it. It provides only getprop and setprop. I think you took my "you can't do that" statements to be a statement about limitations of using a filesystem interfcae -- quite the opposite, I was saying the hv functionality is too limited to support a filesystem interface with normal semantics. > > And what would be the benefit of this major restructuring and added > > complexity? > > I think it would be a slightly better abstraction, and the complexity > is not as big as you make it sound. I'm mainly countering your statement > that it would be a bad interface or that would not possible to do. > > I'm not that opposed to having an ioctl interface for your hypervisor > interface, but I am opposed to making design choices based on > a bad representations of facts or not having considered the options > that other people suggest. I don't really see how a filesystem is a better abstraction for a wrapper around a procedural interface. A somewhat better argument is that ioctls are a pain, and Linux doesn't have a better way to expose a procedural interface, that doesn't require a wrapper program -- though as the wrapper already exists, and the fs interface would probably be sufficiently awkward that people would still use a wrapper, that doesn't buy us too much either. This is not being proposed as any sort of standard kernel API, just a way for userspace to get access to implementation-specific hcalls. Implementation-specific backdoor is practically the definition of ioctl. :-) I would be interested to see a concrete proposal for what this would look like as a filesystem, though, based on the actual operations that are available. How would you deal with getting all the parameters in, performing the operation, and getting the results back? What about when multiple processes are doing this at the same time? What would the memcpy hcall look like? -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 7/7] [v2] drivers/misc: introduce Freescale hypervisor management driver
On Monday 06 June 2011 20:15:16 Scott Wood wrote: > On Mon, 6 Jun 2011 17:53:09 +0200 > Arnd Bergmann wrote: > > > > > You can't delete anything. > > > > > > > > rm, rmdir > > > > > > > > > You can't create empty nodes. > > > > > > > > mkdir > > > > > > I know how to operate a filesystem. You can't do these operations *on > > > another guest's device tree through the hv interface*. > > > > Why not? > > Because the hypervisor does not support it. It provides only getprop and > setprop. I think you took my "you can't do that" statements to be a > statement about limitations of using a filesystem interfcae -- quite the > opposite, I was saying the hv functionality is too limited to support a > filesystem interface with normal semantics. Ok, sorry for the confusion on my part. It makes a lot more sense now. > > > And what would be the benefit of this major restructuring and added > > > complexity? > > > > I think it would be a slightly better abstraction, and the complexity > > is not as big as you make it sound. I'm mainly countering your statement > > that it would be a bad interface or that would not possible to do. > > > > I'm not that opposed to having an ioctl interface for your hypervisor > > interface, but I am opposed to making design choices based on > > a bad representations of facts or not having considered the options > > that other people suggest. > > I don't really see how a filesystem is a better abstraction for a wrapper > around a procedural interface. A somewhat better argument is that ioctls > are a pain, and Linux doesn't have a better way to expose a procedural > interface, that doesn't require a wrapper program -- though as the wrapper > already exists, and the fs interface would probably be sufficiently awkward > that people would still use a wrapper, that doesn't buy us too much either. > > This is not being proposed as any sort of standard kernel API, just a way > for userspace to get access to implementation-specific hcalls. > Implementation-specific backdoor is practically the definition of ioctl. :-) > > I would be interested to see a concrete proposal for what this would look > like as a filesystem, though, based on the actual operations that are > available. How would you deal with getting all the parameters in, > performing the operation, and getting the results back? What about when > multiple processes are doing this at the same time? What would the memcpy > hcall look like? In fs/libfs.c, we have support for "simple transaction files", where you write input parameters into a file and then read it back to get the results. They are very rarely used, but can serve as a way to replace ioctls with file operations where that makes sense. For an inter-partition memcpy, a better interface might be a pipe representation: You have a namespace that is shared between two partitions, so each side can create directory entries with arbitrary names in one of the subdirectories of the file system. Then you can open the file for reading on one side and writing on the other side and when both sides have started the respective operation, the hypervisor will copy data. The possible ways to use that functionality are countless. Similarly, you can mmap a file to get inter-partition shared memory. Arnd ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 7/7] [v2] drivers/misc: introduce Freescale hypervisor management driver
On 6/6/2011 12:24 PM, Arnd Bergmann wrote: > On Monday 06 June 2011, Timur Tabi wrote:. >> And what about my concern that my driver will be the only one in >> drivers/virt? > I have no doubt that more of these will come. Chris Metcalf is currently > looking for a home for his tilera hypervisor drivers, and we have the > microsoft hyperv drivers in drivers/staging, so they will hopefully > move to a proper place later. We also have similar drivers in other > places, e.g. drivers/ps3/ps3-sys-manager.c, drivers/s390/char/vmcp.c > or parts of drivers/xen. It might help if someone (Arnd?) wanted to propose a statement of what drivers/virt was really for. If it's for any Linux driver that upcalls to a hypervisor for any reason, then the Tilera paravirtualized drivers fit in well. If it's intended more for drivers that guests running under a hypervisor can use to talk to the hypervisor itself (e.g. managing notifications that a hypervisor delivers to a guest to cause it to shut down or take other actions), then it doesn't seem like the Tilera paravirtualized device drivers belong there, since they're just using the Tilera hypervisor synchronously to do I/O or get/set device and driver state. -- Chris Metcalf, Tilera Corp. http://www.tilera.com ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH -v2] Audit: push audit success and retcode into arch ptrace.h
From: Eric Paris Date: Fri, 03 Jun 2011 18:04:51 -0400 ... > Signed-off-by: Eric Paris > Acked-by: Acked-by: H. Peter Anvin [for x86 portion] For sparc parts: Acked-by: David S. Miller ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 7/7] [v2] drivers/misc: introduce Freescale hypervisor management driver
On Mon, Jun 06, 2011 at 05:01:36PM -0400, Chris Metcalf wrote: > On 6/6/2011 12:24 PM, Arnd Bergmann wrote: > > On Monday 06 June 2011, Timur Tabi wrote:. > >> And what about my concern that my driver will be the only one in > >> drivers/virt? > > I have no doubt that more of these will come. Chris Metcalf is currently > > looking for a home for his tilera hypervisor drivers, and we have the > > microsoft hyperv drivers in drivers/staging, so they will hopefully > > move to a proper place later. We also have similar drivers in other > > places, e.g. drivers/ps3/ps3-sys-manager.c, drivers/s390/char/vmcp.c > > or parts of drivers/xen. > > It might help if someone (Arnd?) wanted to propose a statement of what > drivers/virt was really for. If it's for any Linux driver that upcalls to Was for? I am not seeing it in v3.0-rc2? > a hypervisor for any reason, then the Tilera paravirtualized drivers fit in > well. If it's intended more for drivers that guests running under a > hypervisor can use to talk to the hypervisor itself (e.g. managing I believe that the code that deals with specific subsystem (so block API for example) would reside in subsystem directory (so drivers/block would have your virtualization block driver). This allows the maintainer of block to make sure your driver is OK. > notifications that a hypervisor delivers to a guest to cause it to shut > down or take other actions), then it doesn't seem like the Tilera That looks to be arch//tilera/virt/ candidate? > paravirtualized device drivers belong there, since they're just using the > Tilera hypervisor synchronously to do I/O or get/set device and driver state. Well, I/O sounds like block API or network API. But then you are also doing management ioctl - which implies "drivers". "drivers/tilera" does not work? > > -- > Chris Metcalf, Tilera Corp. > http://www.tilera.com > > > -- > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] powerpc/5200: dts: digsy_mtc.dts: add timer0 and timer1 gpio properties
timer0 and timer1 pins are used as simple GPIO on this board.
Add gpio-controller and #gpio-cells properties to timer nodes
so that we can control gpio lines using available MPC52xx
GPT driver.
Signed-off-by: Anatolij Gustschin
---
arch/powerpc/boot/dts/digsy_mtc.dts |7 +++
1 files changed, 7 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/boot/dts/digsy_mtc.dts
b/arch/powerpc/boot/dts/digsy_mtc.dts
index e205d17..2aad7ae 100644
--- a/arch/powerpc/boot/dts/digsy_mtc.dts
+++ b/arch/powerpc/boot/dts/digsy_mtc.dts
@@ -23,7 +23,14 @@
soc5200@f000 {
timer@600 { // General Purpose Timer
+ #gpio-cells = <2>;
fsl,has-wdt;
+ gpio-controller;
+ };
+
+ timer@610 {
+ #gpio-cells = <2>;
+ gpio-controller;
};
rtc@800 {
--
1.7.1
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 7/7] [v2] drivers/misc: introduce Freescale hypervisor management driver
For context, the most recent patch for the tile driver in question is here: https://patchwork.kernel.org/patch/843892/ On 6/6/2011 5:23 PM, Konrad Rzeszutek Wilk wrote: > On Mon, Jun 06, 2011 at 05:01:36PM -0400, Chris Metcalf wrote: >> On 6/6/2011 12:24 PM, Arnd Bergmann wrote: >>> On Monday 06 June 2011, Timur Tabi wrote:. And what about my concern that my driver will be the only one in drivers/virt? >>> I have no doubt that more of these will come. Chris Metcalf is currently >>> looking for a home for his tilera hypervisor drivers, and we have the >>> microsoft hyperv drivers in drivers/staging, so they will hopefully >>> move to a proper place later. We also have similar drivers in other >>> places, e.g. drivers/ps3/ps3-sys-manager.c, drivers/s390/char/vmcp.c >>> or parts of drivers/xen. >> It might help if someone (Arnd?) wanted to propose a statement of what >> drivers/virt was really for. If it's for any Linux driver that upcalls to > Was for? I am not seeing it in v3.0-rc2? Sorry, maybe a questionable idiom, but please read past tense in the quoted text as meaning present tense :-) >> a hypervisor for any reason, then the Tilera paravirtualized drivers fit in >> well. If it's intended more for drivers that guests running under a >> hypervisor can use to talk to the hypervisor itself (e.g. managing > I believe that the code that deals with specific subsystem (so block API > for example) would reside in subsystem directory (so drivers/block would have > your virtualization block driver). This allows the maintainer of block > to make sure your driver is OK. Sure, makes sense. The new push (as I understand it) is to group primarily by function, not by bus or architecture. >> notifications that a hypervisor delivers to a guest to cause it to shut >> down or take other actions), then it doesn't seem like the Tilera > That looks to be arch//tilera/virt/ candidate? Arnd, among others, has suggested that all drivers live in "drivers" somewhere, so "arch/tile" may not be the best place. (To be fair, I originally had this driver in arch/tile/drivers/, so your idea is certainly reasonable!) >> paravirtualized device drivers belong there, since they're just using the >> Tilera hypervisor synchronously to do I/O or get/set device and driver state. > Well, I/O sounds like block API or network API. But then you are also > doing management ioctl - which implies "drivers". "drivers/tilera" does not > work? There is certainly precedent for drivers that don't fit cleanly into an existing category to go in drivers/, e.g. drivers/s390, drivers/parisc, etc. There is also drivers/platform/x86, though that seems to be for the bus "platform drivers" rather than just a random character driver like the one in question. I don't have a particular opinion here; I'm just hoping to develop enough consensus that I can ask Linus to pull the driver without generating controversy :-) -- Chris Metcalf, Tilera Corp. http://www.tilera.com ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
