* Re: from narcissus to compilation
From: Tom Rini @ 2011-10-30 17:56 UTC (permalink / raw)
To: openembedded-devel
In-Reply-To: <CAFU7RzOnmbu=dxsM7MZ2DXLrOUMYSN4hoVfAL4W=vJ+Y0vH-Kg@mail.gmail.com>
On Sun, Oct 30, 2011 at 10:23 AM, Raffaele Recalcati
<lamiaposta71@gmail.com> wrote:
> Can anybody tell me, as I got a succesfull compilation on narcissus
> for dm3730-am3715-evm, which is
> the right branch to reproduce the same compilation in order to port
> the kernel to my board?
Well, if you didn't select 'advanced' under build options, it's
probably from the 2011.03-maintenance branch. The rest of it depends
on what image you selected and options and so forth. And since this
is an angstrom image, it's best to ask on their MLs.
--
Tom
^ permalink raw reply
* Re: GATT Dbus API on BlueZ - attirbute-api.txt modifications
From: Anderson Lizardo @ 2011-10-30 18:02 UTC (permalink / raw)
To: Ganir, Chen
Cc: Luiz Augusto von Dentz, Mat Martineau, Claudio Takahasi,
linux-bluetooth@vger.kernel.org, bgix@codeaurora.org,
ingas@codeaurora.org
In-Reply-To: <7769C83744F2C34A841232EF77AEA20C01DCBC47E3@dnce01.ent.ti.com>
Hi Chen,
On Sun, Oct 30, 2011 at 11:48 AM, Ganir, Chen <chen.ganir@ti.com> wrote:
>> > What happens if this value is written from another client ?
>>
>> A property changed signal is emitted, and any client listening to it
>> will know of the new value written to the server. This can be good for
>> consistency between apps looking at the same service IMHO.
>>
> Anderson - what if this value changes from another client from another device?
We have been talking about consistence inside a single host. What has
another "xyz" stack to do with making sure apps on the *same host* can
run together and even access the same services?
> What if this value changes on the server itself, and notification is not enabled? The client will need a way to poll the real time values, and not use a stale or cached value which is a big mistake here.
(This is not how it works on current implementation, but we already
know that right?) You just keep reading the Value property in some
loop in your code:
while <blah>:
read-Value-property
If the connection is up, the ATT commands will be sent as soon as
possible. If not, connection is triggered, and then the ATT read
request/command is sent, and then PropertyChanged signal (should be)
sent.
>> Polling is still possible, you simply keep reading the Value property
>> periodically. If the connection is up, the value comes in "real time".
>> If not, bluez will arrange re-connection in background.
>>
> This is not reflected in the generic API at all. Maybe this functionality is also missing and only present in the proximity profile ?
Taking a look at the current generic API source code, you are right,
it is only happening at Value writes, not read.
Anyway, in Proximity, the characteristic values are not supposed to be
polled (TX Power, for instance, should only read it once on each
connection). So at least for Value reads, it is not useful as example.
>
>> > I could not find in the upstream code any other gatt_read_char ,
>> except for when connection is established.
>>
>> It only makes sense (and only works) if there is a connection up
>> right? If the connection is already up, the "connected" callback will
>> be called immediately (sort of, it may be called on next main loop
>> iteration).
>>
> I don't really see how this makes sense. If the connection is already up, is it forbidden to re-read the value directly from the server ? I did not see in the generic code "get_properties" function any reference to att_io functionality at all -the function just reads the chr variable, and returnes dbus message with the current properties. No attempt to re-read the value is even made.
Same reason as above. The rationale I gave you is based on how attio
connection callbacks work, if the Generic API does not use it yet for
reading values, surely this rationale does not apply to the current
implementation. We are still discussing the API, right?
>> This means: if you register a *intention* to use the connection, and
>> the link is already up, the connected callback is called "immediately"
>> (on next GLIB mainloop iteration).
>>
> I only wrote this since the only possibility available currently for the generic GATT API to read a value from the server is to reconnect. Otherwise, the gatt_read_... function is never called.
Ok, I see a trend here :) We are now discussing about the current
Generic API implementation and not about doc/attribute-api.txt nor
your patch right? Ideally the .txt doc should always reflect the .c
code, but currently it is not the case. I suggest we get back to the
API discussion, then we can fix the code to behave like documented. Is
that ok?
>> Simply because SetProperty() modifies the property, and
>> PropertyChanged() notifies property changes, this way you can notify
>> other clients that a new value has been written on the peer device, as
>> well as the "writer" client. Other clients can ignore the signal if
>> they are not interested on it.
>>
> Other clients running on the same host, connected to the same DBUS (assuming it actually implements this, which currently it does not). If the other client is running on a separate device, it will not get any signal from it's dbus, and will only wait for notification/indication or simply poll periodicall for the value.
I honestly don't see why this matters. We have been talking about
BlueZ consistency on the same host (two or more applications using the
same API), when did another device enter the game?
>> Again, assuming this can be done just like Proximity Monitor, what are
>> your concerns about it?
>>
> Still, I do not think that returning a cached/stale value is the correct way. You intentionally return a bad value, which you know may no longer be the correct one, and risk a client taking decisions upon your assumption that it's ok to return a bad value. Take the health thermometer example again - if the connection is down - the client MUST know about it, and the value should not be returned until it is read from the server again.
If PropertyChanged() were emitted, there would be no such "cache".
Even now, it is not a cache. It is a "read once" behavior, which of
course is inappropriate for any dynamic service (most are dynamic).
If it was meant to be some cache, I think it could be mentioned on the
API document. The reason it is only read once is implementation
limitation, not the API.
>> In my opinion, giving too much control to all clients may risk they
>> not being able to co-operate, making the D-Bus API any better than
>> letting all apps read/write on bluetooth sockets directly.
> I'd like to allow clients to do it because the GATT profile spec allows you to use ANY GATT Client API's such as write with or without response, write a value when the link is not authenticated, or do whatever you like. It's not like opening a socket (GATT or L2cap - same result). GATT Profile is a high level profile, not like the ATT protocol. Taking control of everything, leaving the client no choice is the best practice to avoid problems, but its also the best way to frustrate them when the need to do something which you did not think of at first place. I think making the API a bit more flexible is not going to strain the DBUS or do any harm.
It will simply allow apps to (intentionally or not) mess with each
other, on the *same host* (just to be clear). But I think I repeated
this too much already :)
Also if the spec says "... shall not ..." I think we should really
consider not allowing it on the (D-Bus) API as well.
>> Yes, this is one point where we can surely improve. The current
>> behavior was simply "cloned" from BR/EDR.
>>
>> I think one of the patches Andre Guedes has been working on is a first
>> step on this (actually it is a bug fix to an issue found on UPF where
>> ATT requests made during SMP pairing may be lost), and we should
>> probably send it this week. But we still need to implement support on
>> ATT layer to increase security level when necessary.
>>
> ATT layer does not need to do such a thing ! This is the responsibility of the profile client, and no one elses. The spec specifically defines the ATT error codes regarding the security , and how clients should handle those errors.
It seems you are mapping the Core Spec's "client" definition as a
D-Bus client. This will *not* work. A client (as per Core spec) is
BlueZ. If it it provides external D-Bus API, it is out of scope for
the specification.
BTW, it seems the client.c code already do something like that
(update_char_value()):
else if (status == ATT_ECODE_INSUFF_ENC) {
GIOChannel *io = g_attrib_get_channel(gatt->attrib);
if (bt_io_set(io, BT_IO_L2CAP, NULL,
BT_IO_OPT_SEC_LEVEL, BT_IO_SEC_HIGH,
BT_IO_OPT_INVALID)) {
gatt_read_char(gatt->attrib, chr->handle, 0,
update_char_value, current);
return;
}
}
But for sure it will require review after we agree on how to handle this.
>> I think that, if the spec only allows certain operations on certain
>> conditions (see the "shall only"), the D-Bus should comply to this.
>> This may help a lot when qualifying BlueZ based products against the
>> Core spec. If apps want full control, again, they can use the socket
>> based API (you can even still use the GATT and ATT functions, just
>> like gatttool).
>>
> Anderson - you keep mentioning the socket API - what is that exactly ? Where is it documented? How do we work with it ?
It is the API used by attrib/client.c itself and attrib/gatttool.c. No
documentation AFAIK.
> D-BUS is not the client here. It should not make decisions of a client. The client is the D-BUS user, which will try to build profiles on top of that API according to the specs.
Again, you are assuming a Core spec's "client" as a D-Bus client. This
may mean we have not been on the same page since long :)
>> If you have any interest on Reliable Writes, feel free to propose some
>> API, so we can discuss :).
>>
> Making the write command a generic one as I suggested on my RFC is exactly that, unifying all the write API's into a single call, with parameters.
For Reliable Writes it should simply not work for all its use cases.
It is not atomic as your proposal suggests.
Regards,
--
Anderson Lizardo
Instituto Nokia de Tecnologia - INdT
Manaus - Brazil
^ permalink raw reply
* [Qemu-devel] [PATCH 0/3] xtensa_lx60: FLASH, kernel args support, minor fixes
From: Max Filippov @ 2011-10-30 18:03 UTC (permalink / raw)
To: qemu-devel; +Cc: jcmvbkbc
Max Filippov (3):
xtensa_lx60: add FLASH support
xtensa_lx60: pass kernel arguments from -append
xtensa_lx60: fix build date code and change memory region names
default-configs/xtensa-softmmu.mak | 1 +
default-configs/xtensaeb-softmmu.mak | 1 +
hw/xtensa_bootparam.h | 25 ++++++++
hw/xtensa_lx60.c | 111 +++++++++++++++++++++++++++++-----
4 files changed, 122 insertions(+), 16 deletions(-)
create mode 100644 hw/xtensa_bootparam.h
--
1.7.6.4
^ permalink raw reply
* [Qemu-devel] [PATCH 3/3] xtensa_lx60: fix build date code and change memory region names
From: Max Filippov @ 2011-10-30 18:03 UTC (permalink / raw)
To: qemu-devel; +Cc: jcmvbkbc
In-Reply-To: <1319997794-10542-1-git-send-email-jcmvbkbc@gmail.com>
Fix date code to uses MMDDYYYY notation.
Change memory region names to reflect specification that defines them.
Signed-off-by: Max Filippov <jcmvbkbc@gmail.com>
---
hw/xtensa_lx60.c | 8 ++++----
1 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/hw/xtensa_lx60.c b/hw/xtensa_lx60.c
index 069b21c..8947157 100644
--- a/hw/xtensa_lx60.c
+++ b/hw/xtensa_lx60.c
@@ -63,7 +63,7 @@ static uint64_t lx60_fpga_read(void *opaque, target_phys_addr_t addr,
switch (addr) {
case 0x0: /*build date code*/
- return 0x27092011;
+ return 0x09272011;
case 0x4: /*processor clock frequency, Hz*/
return 10000000;
@@ -107,7 +107,7 @@ static Lx60FpgaState *lx60_fpga_init(MemoryRegion *address_space,
Lx60FpgaState *s = g_malloc(sizeof(Lx60FpgaState));
memory_region_init_io(&s->iomem, &lx60_fpga_ops, s,
- "lx60-fpga", 0x10000);
+ "lx60.fpga", 0x10000);
memory_region_add_subregion(address_space, base, &s->iomem);
lx60_fpga_reset(s);
qemu_register_reset(lx60_fpga_reset, s);
@@ -186,11 +186,11 @@ static void lx_init(const LxBoardDesc *board,
}
ram = g_malloc(sizeof(*ram));
- memory_region_init_ram(ram, NULL, "xtensa.sram", ram_size);
+ memory_region_init_ram(ram, NULL, "lx60.dram", ram_size);
memory_region_add_subregion(system_memory, 0, ram);
system_io = g_malloc(sizeof(*system_io));
- memory_region_init(system_io, "system.io", 224 * 1024 * 1024);
+ memory_region_init(system_io, "lx60.io", 224 * 1024 * 1024);
memory_region_add_subregion(system_memory, 0xf0000000, system_io);
lx60_fpga_init(system_io, 0x0d020000);
if (nd_table[0].vlan) {
--
1.7.6.4
^ permalink raw reply related
* [Qemu-devel] [PATCH 2/3] xtensa_lx60: pass kernel arguments from -append
From: Max Filippov @ 2011-10-30 18:03 UTC (permalink / raw)
To: qemu-devel; +Cc: jcmvbkbc
In-Reply-To: <1319997794-10542-1-git-send-email-jcmvbkbc@gmail.com>
Create boot parameters in the end of SRAM region, insert kernel
arguments specified in -append there.
Signed-off-by: Max Filippov <jcmvbkbc@gmail.com>
---
hw/xtensa_bootparam.h | 25 +++++++++++++++++++++++++
hw/xtensa_lx60.c | 24 ++++++++++++++++++++----
2 files changed, 45 insertions(+), 4 deletions(-)
create mode 100644 hw/xtensa_bootparam.h
diff --git a/hw/xtensa_bootparam.h b/hw/xtensa_bootparam.h
new file mode 100644
index 0000000..38ef32b
--- /dev/null
+++ b/hw/xtensa_bootparam.h
@@ -0,0 +1,25 @@
+#ifndef HW_XTENSA_BOOTPARAM
+#define HW_XTENSA_BOOTPARAM
+
+typedef struct BpTag {
+ uint16_t tag;
+ uint16_t size;
+} BpTag;
+
+static inline ram_addr_t put_tag(ram_addr_t addr, uint16_t tag,
+ size_t size, const void *data)
+{
+ BpTag bp_tag = {
+ .tag = tswap16(tag),
+ .size = tswap16((size + 3) & ~3),
+ };
+
+ cpu_physical_memory_write(addr, &bp_tag, sizeof(bp_tag));
+ addr += sizeof(bp_tag);
+ cpu_physical_memory_write(addr, data, size);
+ addr += (size + 3) & ~3;
+
+ return addr;
+}
+
+#endif
diff --git a/hw/xtensa_lx60.c b/hw/xtensa_lx60.c
index cb047d2..069b21c 100644
--- a/hw/xtensa_lx60.c
+++ b/hw/xtensa_lx60.c
@@ -34,6 +34,7 @@
#include "pc.h"
#include "sysbus.h"
#include "flash.h"
+#include "xtensa_bootparam.h"
typedef struct LxBoardDesc {
size_t flash_size;
@@ -188,10 +189,6 @@ static void lx_init(const LxBoardDesc *board,
memory_region_init_ram(ram, NULL, "xtensa.sram", ram_size);
memory_region_add_subregion(system_memory, 0, ram);
- rom = g_malloc(sizeof(*rom));
- memory_region_init_ram(rom, NULL, "xtensa.rom", 0x1000);
- memory_region_add_subregion(system_memory, 0xfe000000, rom);
-
system_io = g_malloc(sizeof(*system_io));
memory_region_init(system_io, "system.io", 224 * 1024 * 1024);
memory_region_add_subregion(system_memory, 0xf0000000, system_io);
@@ -223,6 +220,25 @@ static void lx_init(const LxBoardDesc *board,
/* Use presence of kernel file name as 'boot from SRAM' switch. */
if (kernel_filename) {
+ rom = g_malloc(sizeof(*rom));
+ memory_region_init_ram(rom, NULL, "lx60.sram", board->sram_size);
+ memory_region_add_subregion(system_memory, 0xfe000000, rom);
+
+ /* Put kernel bootparameters to the end of that SRAM */
+ if (kernel_cmdline) {
+ size_t cmdline_size = strlen(kernel_cmdline) + 1;
+ size_t bp_size = sizeof(BpTag[4]) + cmdline_size;
+ uint32_t tagptr = (0xfe000000 + board->sram_size - bp_size) & ~0xff;
+
+ env->regs[2] = tagptr;
+
+ tagptr = put_tag(tagptr, 0x7b0b, 0, NULL);
+ if (cmdline_size > 1) {
+ tagptr = put_tag(tagptr, 0x1001,
+ cmdline_size, kernel_cmdline);
+ }
+ tagptr = put_tag(tagptr, 0x7e0b, 0, NULL);
+ }
uint64_t elf_entry;
uint64_t elf_lowaddr;
int success = load_elf(kernel_filename, translate_phys_addr, env,
--
1.7.6.4
^ permalink raw reply related
* [Qemu-devel] [PATCH 1/3] xtensa_lx60: add FLASH support
From: Max Filippov @ 2011-10-30 18:03 UTC (permalink / raw)
To: qemu-devel; +Cc: jcmvbkbc
In-Reply-To: <1319997794-10542-1-git-send-email-jcmvbkbc@gmail.com>
LX60 carry 4 Mbyte FLASH and 128 Kbyte SRAM, LX200 carry 16 Mbyte FLASH
and 32 Mbyte SRAM. Either of these memories may be mapped to the system
ROM region.
Select boot from FLASH if -kernel option is not specified, otherwise
boot from SRAM.
Signed-off-by: Max Filippov <jcmvbkbc@gmail.com>
---
default-configs/xtensa-softmmu.mak | 1 +
default-configs/xtensaeb-softmmu.mak | 1 +
hw/xtensa_lx60.c | 79 ++++++++++++++++++++++++++++++---
3 files changed, 73 insertions(+), 8 deletions(-)
diff --git a/default-configs/xtensa-softmmu.mak b/default-configs/xtensa-softmmu.mak
index 7f0df34..9d8899c 100644
--- a/default-configs/xtensa-softmmu.mak
+++ b/default-configs/xtensa-softmmu.mak
@@ -2,3 +2,4 @@
CONFIG_SERIAL=y
CONFIG_OPENCORES_ETH=y
+CONFIG_PFLASH_CFI01=y
diff --git a/default-configs/xtensaeb-softmmu.mak b/default-configs/xtensaeb-softmmu.mak
index 7f0df34..9d8899c 100644
--- a/default-configs/xtensaeb-softmmu.mak
+++ b/default-configs/xtensaeb-softmmu.mak
@@ -2,3 +2,4 @@
CONFIG_SERIAL=y
CONFIG_OPENCORES_ETH=y
+CONFIG_PFLASH_CFI01=y
diff --git a/hw/xtensa_lx60.c b/hw/xtensa_lx60.c
index 3cebca1..cb047d2 100644
--- a/hw/xtensa_lx60.c
+++ b/hw/xtensa_lx60.c
@@ -33,6 +33,13 @@
#include "exec-memory.h"
#include "pc.h"
#include "sysbus.h"
+#include "flash.h"
+
+typedef struct LxBoardDesc {
+ size_t flash_size;
+ size_t flash_sector_size;
+ size_t sram_size;
+} LxBoardDesc;
typedef struct Lx60FpgaState {
MemoryRegion iomem;
@@ -142,8 +149,8 @@ static void lx60_reset(void *env)
cpu_reset(env);
}
-static void lx60_init(ram_addr_t ram_size,
- const char *boot_device,
+static void lx_init(const LxBoardDesc *board,
+ ram_addr_t ram_size, const char *boot_device,
const char *kernel_filename, const char *kernel_cmdline,
const char *initrd_filename, const char *cpu_model)
{
@@ -155,8 +162,14 @@ static void lx60_init(ram_addr_t ram_size,
MemoryRegion *system_memory = get_system_memory();
CPUState *env = NULL;
MemoryRegion *ram, *rom, *system_io;
+ DriveInfo *dinfo;
+ pflash_t *flash = NULL;
int n;
+ if (!cpu_model) {
+ cpu_model = "dc232b";
+ }
+
for (n = 0; n < smp_cpus; n++) {
env = cpu_init(cpu_model);
if (!env) {
@@ -195,6 +208,20 @@ static void lx60_init(ram_addr_t ram_size,
serial_mm_init(system_io, 0x0d050020, 2, xtensa_get_extint(env, 0),
115200, serial_hds[0], DEVICE_NATIVE_ENDIAN);
+ dinfo = drive_get(IF_PFLASH, 0, 0);
+ if (dinfo) {
+ flash = pflash_cfi01_register(0xf8000000,
+ NULL, "lx60.io.flash", board->flash_size,
+ dinfo->bdrv, board->flash_sector_size,
+ board->flash_size / board->flash_sector_size,
+ 4, 0x0000, 0x0000, 0x0000, 0x0000, be);
+ if (flash == NULL) {
+ fprintf(stderr, "Unable to mount pflash\n");
+ exit(1);
+ }
+ }
+
+ /* Use presence of kernel file name as 'boot from SRAM' switch. */
if (kernel_filename) {
uint64_t elf_entry;
uint64_t elf_lowaddr;
@@ -203,6 +230,16 @@ static void lx60_init(ram_addr_t ram_size,
if (success > 0) {
env->pc = elf_entry;
}
+ } else {
+ if (flash) {
+ MemoryRegion *flash_mr = pflash_cfi01_get_memory(flash);
+ MemoryRegion *flash_io = g_malloc(sizeof(*flash_io));
+
+ memory_region_init_alias(flash_io, "lx60.flash",
+ flash_mr, 0, board->flash_size);
+ memory_region_add_subregion(system_memory, 0xfe000000,
+ flash_io);
+ }
}
}
@@ -211,10 +248,28 @@ static void xtensa_lx60_init(ram_addr_t ram_size,
const char *kernel_filename, const char *kernel_cmdline,
const char *initrd_filename, const char *cpu_model)
{
- if (!cpu_model) {
- cpu_model = "dc232b";
- }
- lx60_init(ram_size, boot_device, kernel_filename, kernel_cmdline,
+ static const LxBoardDesc lx60_board = {
+ .flash_size = 0x400000,
+ .flash_sector_size = 0x10000,
+ .sram_size = 0x20000,
+ };
+ lx_init(&lx60_board, ram_size, boot_device,
+ kernel_filename, kernel_cmdline,
+ initrd_filename, cpu_model);
+}
+
+static void xtensa_lx200_init(ram_addr_t ram_size,
+ const char *boot_device,
+ const char *kernel_filename, const char *kernel_cmdline,
+ const char *initrd_filename, const char *cpu_model)
+{
+ static const LxBoardDesc lx200_board = {
+ .flash_size = 0x1000000,
+ .flash_sector_size = 0x20000,
+ .sram_size = 0x2000000,
+ };
+ lx_init(&lx200_board, ram_size, boot_device,
+ kernel_filename, kernel_cmdline,
initrd_filename, cpu_model);
}
@@ -225,9 +280,17 @@ static QEMUMachine xtensa_lx60_machine = {
.max_cpus = 4,
};
-static void xtensa_lx60_machine_init(void)
+static QEMUMachine xtensa_lx200_machine = {
+ .name = "lx200",
+ .desc = "lx200 EVB (dc232b)",
+ .init = xtensa_lx200_init,
+ .max_cpus = 4,
+};
+
+static void xtensa_lx_machines_init(void)
{
qemu_register_machine(&xtensa_lx60_machine);
+ qemu_register_machine(&xtensa_lx200_machine);
}
-machine_init(xtensa_lx60_machine_init);
+machine_init(xtensa_lx_machines_init);
--
1.7.6.4
^ permalink raw reply related
* Re: [Qemu-devel] [PATCH 2/2] [WIP]Added target to build libvdisk
From: Saggi Mizrahi @ 2011-10-30 18:04 UTC (permalink / raw)
To: Blue Swirl; +Cc: qemu-devel
In-Reply-To: <CAAu8pHub420MyyqX1DoMf238O+adcKrV-Ev6U+8mm5dQGXc9-g@mail.gmail.com>
On Sun 30 Oct 2011 07:21:13 PM IST, Blue Swirl wrote:
> On Sun, Oct 30, 2011 at 16:51, Saggi Mizrahi<smizrahi@redhat.com> wrote:
>> RFC: This is my suggestion for wrapping the block layer with another
>> supported API. I added only the bare bones verbs I think we can all agree
>> on.
>
> It can be expected that the API will only grow: file descriptor
> versions, async APIs, thread locks, compat versions etc.
There is no doubt it's going to grow but I intend this to be a tools
API rather then a whole library to write qemu alternatives. My desire
is to expose basic functionality so other tools (like VDSM) can do
image manipulation\conversion\inspection. It is not intended to be
highly optimized but rather simple to use. Further more I suggest it as
a guideline to have it not interfere with qemu's internals so they can
remain optimized.
>
>> Apart from the API please also comment on the Makefile. I kinda stitched
>> it up and I will appreciate comments on it as well.
>>
>> libvdisk is a library that packages qemu's handling of disk images. This
>> allows for other programs to link to it and get access to qemu image
>> file abstractions.
>
> So far, we haven't accepted to export any internals as a library
> because of the API and ABI maintenance burdens. Has anything changed?
In VDSM we want to be able to manipulate images and using qemu-img just
doesn't cut it. I don't intend to export the internal API, rather I
would like to create an alternative simple API that is easier to
maintain that can be consumed by 3rd party. I tried to make the library
independent from internal qemu data structures and low level
functinality so it can be easily maintained.
>
> The licenses of the various files vary, I wonder what conditions
> should the shared library have.
For VDSM GPL is good enough (VDSM being GPL). If there are other
parties interested in making it a more relaxed licence I'm sure there
is way to pull something off. This can always happen down the road. I
know that libvirt would like it to be LGPL. In any case I will submit
my files as LGPL.
>
>> To use install the lib and #include<vdisk.h>
>>
>> Signed-off-by: Saggi Mizrahi<smizrahi@redhat.com>
>> ---
>> .gitignore | 3 +-
>> Makefile.objs | 9 ++++
>> libvdisk/Makefile | 53 +++++++++++++++++++++
>> libvdisk/vdisk.c | 134 +++++++++++++++++++++++++++++++++++++++++++++++++++++
>> libvdisk/vdisk.h | 27 +++++++++++
>> 5 files changed, 224 insertions(+), 2 deletions(-)
>> create mode 100644 libvdisk/Makefile
>> create mode 100644 libvdisk/vdisk.c
>> create mode 100644 libvdisk/vdisk.h
>>
>> diff --git a/.gitignore b/.gitignore
>> index 6d2acab..7221431 100644
>> --- a/.gitignore
>> +++ b/.gitignore
>> @@ -1,5 +1,4 @@
>> -config-devices.*
>> -config-all-devices.*
>> +config-devices.* config-all-devices.*
>> config-host.*
>> config-target.*
>> trace.h
>> diff --git a/Makefile.objs b/Makefile.objs
>> index 01587c8..a355061 100644
>> --- a/Makefile.objs
>> +++ b/Makefile.objs
>> @@ -171,6 +171,15 @@ common-obj-$(CONFIG_XEN_BACKEND) += xen_backend.o xen_devconfig.o
>> common-obj-$(CONFIG_XEN_BACKEND) += xen_console.o xenfb.o xen_disk.o xen_nic.o
>>
>> ######################################################################
>> +# libvdisk
>> +
>> +vdisk-obj-y = $(block-obj-y)
>> +
>> +vdisk-obj-y += qemu-tool.o qemu-error.o vdisk.o
>> +vdisk-obj-y += $(oslib-obj-y) $(trace-obj-y) $(block-obj-y)
>> +vdisk-obj-y += $(qobject-obj-y) $(version-obj-y) qemu-timer-common.o
>> +
>> +######################################################################
>> # libuser
>>
>> user-obj-y =
>> diff --git a/libvdisk/Makefile b/libvdisk/Makefile
>> new file mode 100644
>> index 0000000..6b0a28f
>> --- /dev/null
>> +++ b/libvdisk/Makefile
>> @@ -0,0 +1,53 @@
>> +# Makefile for libvdisk.
>> +
>> +include ../config-host.mak
>> +include $(SRC_PATH)/rules.mak
>> +BUILD_DIR=$(CURDIR)
>> +
>> +.PHONY: all libvdisk block trace install uninstall
>> +
>> +$(call set-vpath, $(SRC_PATH))
>> +
>> +QEMU_CFLAGS+=-I.. -fPIC -I$(BUILD_DIR)
>> +
>> +include $(SRC_PATH)/Makefile.objs
>> +
>> +libvdisk: block block.o libvdisk.so.1.0
>
> A variable should be defined for 1.0 and used here and elsewhere.
>
>> +
>> +$(BUILD_DIR)/config-host.mak: ../config-host.mak
>> + ln -sf $< $@
>> +
>> +# Copy because I build the obj with -fPIC which is not needed
>> +# for regular qemu build
>> +block: trace
>> + mkdir -p block
>> + ln -sf $(SRC_PATH)/block/*.[ch] block
>> +trace: trace.h
>> + mkdir -p trace
>> + ln -sf $(SRC_PATH)/trace/*.[chd] trace
>> +
>> +libvdisk.so.1.0: $(vdisk-obj-y)
>> + $(LD) -shared -soname $@ -o $@ -lc $^
>> +
>> +install: libvdisk
>> + $(INSTALL) vdisk.h $(PREFIX)$(includedir)
>> + $(INSTALL) libvdisk.so.1.0 $(PREFIX)$(libdir)
>> + ln -sf $(PREFIX)$(libdir)/libvdisk.so.1.0 $(PREFIX)$(libdir)/libvdisk.so.1
>> + ln -sf $(PREFIX)$(libdir)/libvdisk.so.1.0 $(PREFIX)$(libdir)/libvdisk.so
>> +
>> +uninstall:
>> + rm -rf $(PREFIX)$(includedir)/vdisk
>> + rm -f $(PREFIX)$(libdir)/libvdisk.so.*
>> +
>> +all: libvdisk
>> +
>> +clean:
>> + rm -rf block/
>> + rm -rf trace/
>> + rm -f *.[od]
>> + rm -f *.mak
>> + rm -f trace*
>> + rm -f libvdisk.so.*
>> +
>> +# Include automatically generated dependency files
>> +-include $(wildcard *.d */*.d)
>> diff --git a/libvdisk/vdisk.c b/libvdisk/vdisk.c
>> new file mode 100644
>> index 0000000..d28862d
>> --- /dev/null
>> +++ b/libvdisk/vdisk.c
>> @@ -0,0 +1,134 @@
>
> There is no header, please specify the license.
>
>> +#include "vdisk.h"
>> +
>> +#include<pthread.h>
>> +#include "block.h"
>> +
>> +typedef struct t_virtual_disk {
>> + BlockDriverState *bs;
>> + pthread_mutex_t mtx;
>> +
>> +} VirtualDisk;
>> +
>> +void vdisk_init(void) {
>> + bdrv_init();
>> +}
>> +
>> +static int open_bdrv_from_path(const char* path, BlockDriverState** bs,
>
> Asterisks should reside close to the variable name, not the type.
>
>> + int flags, const char* format) {
>> + int rc;
>> + BlockDriver* driver;
>> +
>> + *bs = bdrv_new(path);
>> + if (format == NULL) {
>> + driver = NULL;
>> + } else {
>> + driver = bdrv_find_format(format);
>> + if (driver == NULL) {
>> + return -EINVAL;
>> + }
>> + }
>> +
>> + rc = bdrv_open(*bs, path, flags, driver);
>> + if (rc< 0) {
>> + bdrv_delete(*bs);
>> + }
>> + return rc;
>> +}
>> +
>> +int vdisk_create(const char *filename, const char *fmt,
>> + const char *base_filename, const char *base_fmt,
>> + char *options, uint64_t img_size, int flags) {
>> +
>> + return bdrv_img_create(filename, fmt, base_filename, base_fmt,
>> + options, img_size, flags);
>> +}
>> +
>> +int vdisk_open(VDD* vdd, const char* pathname, int flags, const char* format) {
>> + int rc;
>> + VirtualDisk* vd = malloc(sizeof(VirtualDisk));
>> + if (!vd) { return -ENOMEM; }
>> +
>> + rc = open_bdrv_from_path(pathname,&vd->bs, flags, format);
>> + if (rc< 0) {
>> + goto free_vd;
>> + }
>> +
>> + rc = pthread_mutex_init(&vd->mtx, NULL);
>
> I wonder also what thread API should be used, qemu_thread versions
> used internally or standard ones. It would be logical to use
> qemu_thread versions but then the external user should use those too.
I would prefer not to use qemu's threading as it'll expose internal
APIs. I suggest glib's threading,
>
>> + if (rc != 0) {
>> + rc = -rc;
>> + goto free_bs;
>> + }
>> +
>> + vdd->virtual_disk = vd;
>> +
>> + return 0;
>> +
>> +free_bs:
>> + bdrv_delete(vd->bs);
>> +free_vd:
>> + free(vd);
>> + return rc;
>> +}
>> +
>> +ssize_t vdisk_pread(VDD* vdd, void *buf, size_t count, off_t offset) {
>> + int rc;
>> + uint64_t totalSectors;
>> + VirtualDisk* vd = vdd->virtual_disk;
>> + if (!vd) {
>> + return -EBADF;
>> + }
>> +
>> + pthread_mutex_lock(&vd->mtx);
>> + bdrv_get_geometry(vd->bs,&totalSectors);
>> + if ((totalSectors * 512)<= offset) {
>> + rc = 0;
>> + goto end;
>> + }
>> +
>> + rc = bdrv_pread(vd->bs, offset, buf, count);
>> +end:
>> + pthread_mutex_unlock(&vd->mtx);
>> + return rc;
>> +}
>> +
>> +ssize_t vdisk_pwrite(VDD* vdd, const void *buf, size_t count, off_t offset) {
>> + int rc;
>> + uint64_t totalSectors;
>> + VirtualDisk* vd = vdd->virtual_disk;
>> + if (!vd) {
>> + return -EBADF;
>> + }
>> +
>> + pthread_mutex_lock(&vd->mtx);
>> + bdrv_get_geometry(vd->bs,&totalSectors);
>> + if ((totalSectors * 512)<= offset) {
>> + rc = 0;
>> + goto end;
>> + }
>> +
>> + rc = bdrv_pwrite(vd->bs, offset, buf, count);
>> +end:
>> + pthread_mutex_unlock(&vd->mtx);
>> + return rc;
>> +}
>> +
>> +int vdisk_flush(VDD* vdd) {
>> + VirtualDisk* vd = vdd->virtual_disk;
>> + if (!vd) {
>> + return -EBADF;
>> + }
>> +
>> + return bdrv_flush(vd->bs);
>> +}
>> +
>> +int vdisk_close(VDD* vdd) {
>> + VirtualDisk* vd = vdd->virtual_disk;
>> + if (!vd) {
>> + return -EBADF;
>> + }
>> +
>> + bdrv_flush(vd->bs);
>> + bdrv_delete(vd->bs);
>> + memset(vdd, 0, sizeof(VDD));
>> + return 0;
>> +}
>> diff --git a/libvdisk/vdisk.h b/libvdisk/vdisk.h
>> new file mode 100644
>> index 0000000..6dba7a3
>> --- /dev/null
>> +++ b/libvdisk/vdisk.h
>> @@ -0,0 +1,27 @@
>
> License header missing.
>
>> +#include<unistd.h>
>> +#include<inttypes.h>
>> +
>> +#define VDISK_O_RDWR 0x0002
>> +#define VDISK_O_SNAPSHOT 0x0008 /* open the file read only and save writes in a snapshot */
>> +#define VDISK_O_NOCACHE 0x0020 /* do not use the host page cache */
>> +#define VDISK_O_CACHE_WB 0x0040 /* use write-back caching */
>> +#define VDISK_O_NATIVE_AIO 0x0080 /* use native AIO instead of the thread pool */
>> +#define VDISK_O_NO_BACKING 0x0100 /* don't open the backing file */
>> +#define VDISK_O_NO_FLUSH 0x0200 /* disable flushing on this disk */
>> +
>> +#define DEFAULT_MAX_DESCIPTORS 1000
>
> DESCRIPTORS, but actually it is unused.
>
>> +
>> +typedef struct t_virtual_disk_descriptor {
>
> t_virtual_disk_descriptor should be VDD.
>
>> + void* virtual_disk;
>> +} VDD;
>> +
>> +void vdisk_init(void);
>> +
>> +int vdisk_create(const char *filename, const char *fmt,
>> + const char *base_filename, const char *base_fmt,
>> + char *options, uint64_t img_size, int flags);
>> +int vdisk_open(VDD* vdd, const char* pathname, int flags, const char* format);
>> +ssize_t vdisk_pread(VDD* vdd, void *buf, size_t count, off_t offset);
>> +ssize_t vdisk_pwrite(VDD* vdd, const void *buf, size_t count, off_t offset);
>> +int vdisk_flush(VDD* vdd);
>> +int vdisk_close(VDD* vdd);
>> --
>> 1.7.7
>>
>>
>>
Thank you, All comments will be addressed. But I would like to get a
green light for the whole process before sending another version.
^ permalink raw reply
* Re: time: Improve documentation of timekeeeping_adjust()
From: Andy Moreton @ 2011-10-30 17:14 UTC (permalink / raw)
To: linux-kernel
In-Reply-To: <1319785345.23224.75.camel@work-vm>
On Fri 28 Oct 2011, John Stultz wrote:
> On Fri, 2011-10-28 at 08:05 +0200, Richard Cochran wrote:
>> On Thu, Oct 27, 2011 at 06:12:42PM -0700, John Stultz wrote:
>> > diff --git a/kernel/time/timekeeping.c b/kernel/time/timekeeping.c
>> > index a5846a8..de8737e 100644
>> > --- a/kernel/time/timekeeping.c
>> > +++ b/kernel/time/timekeeping.c
>> > @@ -802,14 +802,44 @@ static void timekeeping_adjust(s64 offset)
>> > s64 error, interval = timekeeper.cycle_interval;
>> > int adj;
>> >
>> > + /*
>> > + * The point of this is to check if the error is greater then half
>> > + * an interval.
>> > + *
>> > + * First we shift it down from NTP_SHIFT to clocksource->shifted nsecs.
>> > + *
>> > + * Note we subtract one in the shift, so that error is really error*2.
>> > + * This "saves" dividing(shifting) intererval twice, but keeps the
>> > + * (error > interval) comparision as still measuring if error is
>> > + * larger then half an interval.
>> > + *
>> > + * Note: It does not "save" on aggrivation when reading the code.
>>
>> ... or on "aggravation" either :)
>
> Sigh. I do need to start using an editor with built in spell checking.
> I'm so poor of a speller (and a typist) its really amazing its not
> worse.
>
> Thanks for catching that.
> -john
s/intererval/interval/
AndyM
^ permalink raw reply
* Re: >Re: [RFC] should VM_BUG_ON(cond) really evaluate cond
From: Linus Torvalds @ 2011-10-30 18:09 UTC (permalink / raw)
To: Eric Dumazet
Cc: Andi Kleen, Ben Hutchings, linux-kernel, netdev, Andrew Morton
In-Reply-To: <1319997593.13597.76.camel@edumazet-laptop>
On Sun, Oct 30, 2011 at 10:59 AM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
>
> As I said, because v can be a const pointer provided by the caller.
>
> Try it yourself and you'll discover hundred of call sites doing
>
> .... some_function(const struct *xxx, ...)
> {
> if (atomic_read(&xxx->refcnt) <= 0)
> do_something();
Argh. Ok. Testing a refcount in a const struct doesn't make much
sense, but there does seem to be perfectly valid uses of it
(sk_wmem_alloc etc).
Annoying. I guess we have to have those casts. Grr.
Linus
^ permalink raw reply
* [U-Boot] PATCH: Add "time" command
From: Mike Frysinger @ 2011-10-30 18:15 UTC (permalink / raw)
To: u-boot
In-Reply-To: <20111030155515.31F46180985A@gemini.denx.de>
On Sunday 30 October 2011 11:55:15 Wolfgang Denk wrote:
> Mike Frysinger wrote:
> > > Add 'time <cmd> <args>' which executes <cmd> with <args> and shows the
> > > execution time in seconds. Requires get_timer().
> >
> > NAK: we already have common/cmd_time.c and CONFIG_CMD_TIME
>
> But common/cmd_time.c is unportable and only available on ARM due so
> using a non standard timer API (get_timer_masked() etc.
i think the idea was to use the more exact API like will be available with
Graeme's proposed rewrite ...
> I wonder if we should swap the implementations.
extending the current code to support non-ARM makes sense, but adding a new
code base like the original patch does not
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
Url : http://lists.denx.de/pipermail/u-boot/attachments/20111030/6706434c/attachment.pgp
^ permalink raw reply
* [U-Boot] [PATCH v6 1/4] lcd: add clear and draw bitmap declaration
From: Anatolij Gustschin @ 2011-10-30 18:21 UTC (permalink / raw)
To: u-boot
In-Reply-To: <1319187862-31863-2-git-send-email-clchiou@chromium.org>
From: Che-liang Chiou <clchiou@chromium.org>
The functions for clearing and drawing bitmaps on the screen were not
exposed publicly and are made public in this patch in preparation for
implementing the display interface of api_public.h.
Signed-off-by: Che-Liang Chiou <clchiou@chromium.org>
Acked-by: Mike Frysinger <vapier@gentoo.org>
Signed-off-by: Anatolij Gustschin <agust@denx.de>
---
Changes since V5:
- fix compile issues:
lcd.c:81: error: conflicting types for 'lcd_clear'
/home/ag/u-boot/u-boot-video/include/lcd.h:213: error: previous declaration of 'lcd_clear' was here
lcd.c: In function 'do_lcd_clear':
lcd.c:359: error: too few arguments to function 'lcd_clear'
lcd.c: At top level:
lcd.c:364: error: conflicting types for 'lcd_clear'
lcd.c:81: error: previous declaration of 'lcd_clear' was here
lcd.c: In function 'lcd_clear':
lcd.c:405: warning: 'return' with a value, in function returning void
lcd.c: At top level:
lcd.c:408: warning: initialization from incompatible pointer type
make[1]: *** [lcd.o] Error 1
make: *** [common/libcommon.o] Error 2
common/cmd_bmp.c | 4 +---
common/lcd.c | 16 ++++++++++------
include/lcd.h | 2 ++
3 files changed, 13 insertions(+), 9 deletions(-)
diff --git a/common/cmd_bmp.c b/common/cmd_bmp.c
index 23fc82f..682f395 100644
--- a/common/cmd_bmp.c
+++ b/common/cmd_bmp.c
@@ -237,9 +237,7 @@ static int bmp_display(ulong addr, int x, int y)
}
#if defined(CONFIG_LCD)
- extern int lcd_display_bitmap (ulong, int, int);
-
- ret = lcd_display_bitmap ((unsigned long)bmp, x, y);
+ ret = lcd_display_bitmap((ulong)bmp, x, y);
#elif defined(CONFIG_VIDEO)
extern int video_display_bitmap (ulong, int, int);
diff --git a/common/lcd.c b/common/lcd.c
index d9cb8ca..20e97b9 100644
--- a/common/lcd.c
+++ b/common/lcd.c
@@ -78,7 +78,6 @@ static inline void lcd_putc_xy (ushort x, ushort y, uchar c);
static int lcd_init (void *lcdbase);
-static int lcd_clear (cmd_tbl_t * cmdtp, int flag, int argc, char * const argv[]);
static void *lcd_logo (void);
static int lcd_getbgcolor (void);
@@ -353,7 +352,14 @@ int drv_lcd_init (void)
}
/*----------------------------------------------------------------------*/
-static int lcd_clear (cmd_tbl_t * cmdtp, int flag, int argc, char * const argv[])
+static
+int do_lcd_clear(cmd_tbl_t *cmdtp, int flag, int argc, char *const argv[])
+{
+ lcd_clear();
+ return 0;
+}
+
+void lcd_clear(void)
{
#if LCD_BPP == LCD_MONOCHROME
/* Setting the palette */
@@ -394,12 +400,10 @@ static int lcd_clear (cmd_tbl_t * cmdtp, int flag, int argc, char * const argv[]
console_col = 0;
console_row = 0;
-
- return (0);
}
U_BOOT_CMD(
- cls, 1, 1, lcd_clear,
+ cls, 1, 1, do_lcd_clear,
"clear screen",
""
);
@@ -413,7 +417,7 @@ static int lcd_init (void *lcdbase)
lcd_ctrl_init (lcdbase);
lcd_is_enabled = 1;
- lcd_clear (NULL, 1, 1, NULL); /* dummy args */
+ lcd_clear();
lcd_enable ();
/* Initialize the console */
diff --git a/include/lcd.h b/include/lcd.h
index 89cc90c..83b50f4 100644
--- a/include/lcd.h
+++ b/include/lcd.h
@@ -210,6 +210,8 @@ void lcd_disable (void);
void lcd_putc (const char c);
void lcd_puts (const char *s);
void lcd_printf (const char *fmt, ...);
+void lcd_clear(void);
+int lcd_display_bitmap(ulong bmp_image, int x, int y);
/* Allow boards to customize the information displayed */
void lcd_show_board_info(void);
--
1.7.1
^ permalink raw reply related
* Re: [Qemu-devel] Why some ARM NEON helper functions need mask?
From: Chih-Min Chao @ 2011-10-30 18:21 UTC (permalink / raw)
To: 陳韋任; +Cc: qemu-devel
In-Reply-To: <20111030113908.GA18904@cs.nctu.edu.tw>
On Sun, Oct 30, 2011 at 7:39 PM, 陳韋任 <chenwj@iis.sinica.edu.tw> wrote:
> Hi, all
>
> I am looking into QEMU's implementation for ARM NEON instructions
> (target-arm/neon_helper.c). Some helper functions will do mask
> operation, neon_add_u8, for example. I thought simply adding a and b
> is enough and can't figure out why the mask operation is needed.
>
> ---
> uint32_t HELPER(neon_add_u8)(uint32_t a, uint32_t b)
> {
> uint32_t mask;
> mask = (a ^ b) & 0x80808080u;
> a &= ~0x80808080u;
> b &= ~0x80808080u;
> return (a + b) ^ mask;
> }
> ---
>
ex :
a = 0x01 01 01 01
b = 0xFF FF FF FF
the expected result of a+ b is
0x0 0 0 0
simply add a to b is
0x1 1 1 0
> Any help is appreciated.
>
> Regards,
> chenwj
>
> --
> Wei-Ren Chen (陳韋任)
> Computer Systems Lab, Institute of Information Science,
> Academia Sinica, Taiwan (R.O.C.)
> Tel:886-2-2788-3799 #1667
>
>
^ permalink raw reply
* [U-Boot] [PATCH v6 2/4] tools: logo: split bmp arrays from bmp_logo.h
From: Anatolij Gustschin @ 2011-10-30 18:24 UTC (permalink / raw)
To: u-boot
In-Reply-To: <1319187862-31863-3-git-send-email-clchiou@chromium.org>
From: Che-liang Chiou <clchiou@chromium.org>
The generated header bmp_logo.h is useful even outside common/lcd.c for
the logo dimension. However, the problem is, the generated bmp_logo.h
cannot be included multiple times because bmp_logo_palette[] and
bmp_logo_bitmap[] are defined in the bmp_logo.h.
This patch fixes this by defining these arrays in another header
bmp_logo_data.h and in bmp_logo.h only declaring these arrays.
Signed-off-by: Che-Liang Chiou <clchiou@chromium.org>
Acked-by: Mike Frysinger <vapier@gentoo.org>
Signed-off-by: Anatolij Gustschin <agust@denx.de>
---
Changes since V5:
- add bmp_logo_data.h to .gitignore
Makefile | 1 +
common/lcd.c | 1 +
drivers/video/cfb_console.c | 1 +
include/.gitignore | 1 +
tools/Makefile | 8 ++++-
tools/bmp_logo.c | 80 ++++++++++++++++++++++++++++++++-----------
6 files changed, 71 insertions(+), 21 deletions(-)
diff --git a/Makefile b/Makefile
index 9ef33f9..b620e75 100644
--- a/Makefile
+++ b/Makefile
@@ -866,6 +866,7 @@ clean:
$(obj)arch/blackfin/cpu/bootrom-asm-offsets.[chs] \
$(obj)arch/blackfin/cpu/init.{lds,elf}
@rm -f $(obj)include/bmp_logo.h
+ @rm -f $(obj)include/bmp_logo_data.h
@rm -f $(obj)lib/asm-offsets.s
@rm -f $(obj)include/generated/asm-offsets.h
@rm -f $(obj)$(CPUDIR)/$(SOC)/asm-offsets.s
diff --git a/common/lcd.c b/common/lcd.c
index 20e97b9..504b8f6 100644
--- a/common/lcd.c
+++ b/common/lcd.c
@@ -63,6 +63,7 @@
/************************************************************************/
#ifdef CONFIG_LCD_LOGO
# include <bmp_logo.h> /* Get logo data, width and height */
+# include <bmp_logo_data.h>
# if (CONSOLE_COLOR_WHITE >= BMP_LOGO_OFFSET) && (LCD_BPP != LCD_COLOR16)
# error Default Color Map overlaps with Logo Color Map
# endif
diff --git a/drivers/video/cfb_console.c b/drivers/video/cfb_console.c
index 1863563..24e5761 100644
--- a/drivers/video/cfb_console.c
+++ b/drivers/video/cfb_console.c
@@ -285,6 +285,7 @@ void console_cursor(int state);
#ifdef CONFIG_VIDEO_LOGO
#ifdef CONFIG_VIDEO_BMP_LOGO
#include <bmp_logo.h>
+#include <bmp_logo_data.h>
#define VIDEO_LOGO_WIDTH BMP_LOGO_WIDTH
#define VIDEO_LOGO_HEIGHT BMP_LOGO_HEIGHT
#define VIDEO_LOGO_LUT_OFFSET BMP_LOGO_OFFSET
diff --git a/include/.gitignore b/include/.gitignore
index ec224c5..7cd3e90 100644
--- a/include/.gitignore
+++ b/include/.gitignore
@@ -1,5 +1,6 @@
/autoconf.mk*
/asm
/bmp_logo.h
+/bmp_logo_data.h
/config.h
/config.mk
diff --git a/tools/Makefile b/tools/Makefile
index df56a25..948ec19 100644
--- a/tools/Makefile
+++ b/tools/Makefile
@@ -111,8 +111,11 @@ LIBFDT_OBJ_FILES-y += fdt_wip.o
# Generated LCD/video logo
LOGO_H = $(OBJTREE)/include/bmp_logo.h
+LOGO_DATA_H = $(OBJTREE)/include/bmp_logo_data.h
LOGO-$(CONFIG_LCD_LOGO) += $(LOGO_H)
+LOGO-$(CONFIG_LCD_LOGO) += $(LOGO_DATA_H)
LOGO-$(CONFIG_VIDEO_LOGO) += $(LOGO_H)
+LOGO-$(CONFIG_VIDEO_LOGO) += $(LOGO_DATA_H)
ifeq ($(LOGO_BMP),)
LOGO_BMP= logos/denx.bmp
@@ -236,7 +239,10 @@ else
endif
$(LOGO_H): $(obj)bmp_logo $(LOGO_BMP)
- $(obj)./bmp_logo $(LOGO_BMP) >$@
+ $(obj)./bmp_logo --gen-info $(LOGO_BMP) > $@
+
+$(LOGO_DATA_H): $(obj)bmp_logo $(LOGO_BMP)
+ $(obj)./bmp_logo --gen-data $(LOGO_BMP) > $@
#########################################################################
diff --git a/tools/bmp_logo.c b/tools/bmp_logo.c
index 47228d2..b2ad3d5 100644
--- a/tools/bmp_logo.c
+++ b/tools/bmp_logo.c
@@ -1,5 +1,10 @@
#include "compiler.h"
+enum {
+ MODE_GEN_INFO,
+ MODE_GEN_DATA
+};
+
typedef struct bitmap_s { /* bitmap description */
uint16_t width;
uint16_t height;
@@ -9,6 +14,11 @@ typedef struct bitmap_s { /* bitmap description */
#define DEFAULT_CMAP_SIZE 16 /* size of default color map */
+void usage(const char *prog)
+{
+ fprintf(stderr, "Usage: %s [--gen-info|--gen-data] file\n", prog);
+}
+
/*
* Neutralize little endians.
*/
@@ -39,21 +49,52 @@ int error (char * msg, FILE *fp)
exit (EXIT_FAILURE);
}
+void gen_info(bitmap_t *b, uint16_t n_colors)
+{
+ printf("/*\n"
+ " * Automatically generated by \"tools/bmp_logo\"\n"
+ " *\n"
+ " * DO NOT EDIT\n"
+ " *\n"
+ " */\n\n\n"
+ "#ifndef __BMP_LOGO_H__\n"
+ "#define __BMP_LOGO_H__\n\n"
+ "#define BMP_LOGO_WIDTH\t\t%d\n"
+ "#define BMP_LOGO_HEIGHT\t\t%d\n"
+ "#define BMP_LOGO_COLORS\t\t%d\n"
+ "#define BMP_LOGO_OFFSET\t\t%d\n\n"
+ "extern unsigned short bmp_logo_palette[];\n"
+ "extern unsigned char bmp_logo_bitmap[];\n\n"
+ "#endif /* __BMP_LOGO_H__ */\n",
+ b->width, b->height, n_colors,
+ DEFAULT_CMAP_SIZE);
+}
+
int main (int argc, char *argv[])
{
- int i, x;
+ int mode, i, x;
FILE *fp;
bitmap_t bmp;
bitmap_t *b = &bmp;
uint16_t data_offset, n_colors;
- if (argc < 2) {
- fprintf (stderr, "Usage: %s file\n", argv[0]);
+ if (argc < 3) {
+ usage(argv[0]);
exit (EXIT_FAILURE);
}
- if ((fp = fopen (argv[1], "rb")) == NULL) {
- perror (argv[1]);
+ if (!strcmp(argv[1], "--gen-info"))
+ mode = MODE_GEN_INFO;
+ else if (!strcmp(argv[1], "--gen-data"))
+ mode = MODE_GEN_DATA;
+ else {
+ usage(argv[0]);
+ exit(EXIT_FAILURE);
+ }
+
+ fp = fopen(argv[2], "rb");
+ if (!fp) {
+ perror(argv[2]);
exit (EXIT_FAILURE);
}
@@ -92,28 +133,26 @@ int main (int argc, char *argv[])
n_colors = 256 - DEFAULT_CMAP_SIZE;
}
- printf ("/*\n"
+ if (mode == MODE_GEN_INFO) {
+ gen_info(b, n_colors);
+ goto out;
+ }
+
+ printf("/*\n"
" * Automatically generated by \"tools/bmp_logo\"\n"
" *\n"
" * DO NOT EDIT\n"
" *\n"
" */\n\n\n"
- "#ifndef __BMP_LOGO_H__\n"
- "#define __BMP_LOGO_H__\n\n"
- "#define BMP_LOGO_WIDTH\t\t%d\n"
- "#define BMP_LOGO_HEIGHT\t\t%d\n"
- "#define BMP_LOGO_COLORS\t\t%d\n"
- "#define BMP_LOGO_OFFSET\t\t%d\n"
- "\n",
- b->width, b->height, n_colors,
- DEFAULT_CMAP_SIZE);
+ "#ifndef __BMP_LOGO_DATA_H__\n"
+ "#define __BMP_LOGO_DATA_H__\n\n");
/* allocate memory */
if ((b->data = (uint8_t *)malloc(b->width * b->height)) == NULL)
error ("Error allocating memory for file", fp);
/* read and print the palette information */
- printf ("unsigned short bmp_logo_palette[] = {\n");
+ printf("unsigned short bmp_logo_palette[] = {\n");
for (i=0; i<n_colors; ++i) {
b->palette[(int)(i*3+2)] = fgetc(fp);
@@ -137,14 +176,13 @@ int main (int argc, char *argv[])
printf ("\n");
printf ("};\n");
printf ("\n");
- printf ("unsigned char bmp_logo_bitmap[] = {\n");
+ printf("unsigned char bmp_logo_bitmap[] = {\n");
for (i=(b->height-1)*b->width; i>=0; i-=b->width) {
for (x = 0; x < b->width; x++) {
b->data[(uint16_t) i + x] = (uint8_t) fgetc (fp) \
+ DEFAULT_CMAP_SIZE;
}
}
- fclose (fp);
for (i=0; i<(b->height*b->width); ++i) {
if ((i%8) == 0)
@@ -156,8 +194,10 @@ int main (int argc, char *argv[])
}
printf ("\n"
"};\n\n"
- "#endif /* __BMP_LOGO_H__ */\n"
+ "#endif /* __BMP_LOGO_DATA_H__ */\n"
);
- return (0);
+out:
+ fclose(fp);
+ return 0;
}
--
1.7.1
^ permalink raw reply related
* Re: [PATCH] gitweb/Makefile: Remove static/gitweb.js in the clean target
From: Ramsay Jones @ 2011-10-29 19:59 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jakub Narebski, Drew Northup, GIT Mailing-list
In-Reply-To: <7vk47qz5na.fsf@alter.siamese.dyndns.org>
Junio C Hamano wrote:
> Ramsay Jones <ramsay@ramsay1.demon.co.uk> writes:
>
>>> gitweb.js is nowadays a generated file. Though that bit should be
>>> in commit message...
>> Yep, will do ...
>
> Thanks; here is what I already queued.
Yeah, I saw this about two hours after I sent those emails ...
Also, I prefer your commit message! ;-)
Thanks.
ATB,
Ramsay Jones
^ permalink raw reply
* Re: [PATCH] Add CHAR and MISC driver maintainer entry
From: Arnd Bergmann @ 2011-10-30 18:27 UTC (permalink / raw)
To: Greg KH; +Cc: linux-kernel
In-Reply-To: <20111030143404.GA31841@kroah.com>
On Sunday 30 October 2011, Greg KH wrote:
> Arnd, is the patch below ok with you? I'll create the git tree when
> 3.2-rc1 is out and start adding stuff when needed for the 3.3 merge (and
> for 3.2-final if there are any needed bug fixes.
Yes, looks good to me.
Arnd
> From: Greg Kroah-Hartman <gregkh@suse.de>
> Subject: MAINTAINERS: add CHAR and MISC driver maintainers
>
> Yes, we are fools, but humor us.
>
>
> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Acked-by: Arnd Bergmann <arnd@arndb.de>
^ permalink raw reply
* [U-Boot] [PATCH V5 3/4] font: split font data from video_font.h
From: Anatolij Gustschin @ 2011-10-30 18:33 UTC (permalink / raw)
To: u-boot
In-Reply-To: <1319187862-31863-4-git-send-email-clchiou@chromium.org>
Hi,
On Fri, 21 Oct 2011 17:04:21 +0800
Che-Liang Chiou <clchiou@chromium.org> wrote:
...
> include/video_font.h | 4614 +--------------------------------------
> include/video_font_data.h | 4639 +++++++++++++++++++++++++++++++++++++++
> 7 files changed, 4647 insertions(+), 4614 deletions(-)
> create mode 100644 include/video_font_data.h
Please next time additionally use '-C' Option for 'git format-patch ...'
when generating patches with code movement. It will produce
smaller patches, e.g.:
...
include/video_font.h | 4614 +--------------------------
include/{video_font.h => video_font_data.h} | 9 +-
7 files changed, 10 insertions(+), 4621 deletions(-)
copy include/{video_font.h => video_font_data.h} (99%)
But you do not have to resubmit this patch, I think.
Thanks,
Anatolij
^ permalink raw reply
* [U-Boot] Patch Submission - Mend mkimage getline errors for Max OS X 10.7
From: Mike Frysinger @ 2011-10-30 18:38 UTC (permalink / raw)
To: u-boot
In-Reply-To: <3D85623866263F419A189F3EB65CB35902E1333B@CH1PRD0202MB170.namprd02.prod.outlook.com>
On Wednesday 26 October 2011 15:43:11 Bradley, Brandon L wrote:
> This fixes the getline definition in OS X Lion. Apple's stdio library comes
> with getline now. This change comes from Joseph Roback via OpenWRT, here
> is a link. This commit should be contributed to him.
>
> http://patchwork.openwrt.org/patch/1271/
>
> CC if you will.
the patch will need to be submitted properly ...
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
Url : http://lists.denx.de/pipermail/u-boot/attachments/20111030/c401a70f/attachment.pgp
^ permalink raw reply
* Re: [PATCH] drm/i915: collect more per ring error state
From: Chris Wilson @ 2011-10-30 18:39 UTC (permalink / raw)
To: intel-gfx; +Cc: Daniel Vetter
In-Reply-To: <1318360821-1655-1-git-send-email-daniel.vetter@ffwll.ch>
On Tue, 11 Oct 2011 21:20:21 +0200, Daniel Vetter <daniel.vetter@ffwll.ch> wrote:
> Based on a patch by Ben Widawsky, but with different colors
> for the bikeshed.
>
> In contrast to Ben's patch this one doesn't add the fault regs.
> Afaics they're for the optional page fault support which
> - we're not enabling
> - and which seems to be unsupported by the hw team. Recent bspec
> lacks tons of information about this that the public docs released
> half a year back still contain.
>
> Also dump ring HEAD/TAIL registers - I've recently seen a few
> error_state where just guessing these is not good enough.
>
> v2: Also dump INSTPM for every ring.
>
> v3: Fix a few really silly goof-ups spotted by Chris Wilson.
>
> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
This is independent of the "hangcheck robustification" (which I feel is
false advertising ;-) and adds some mildly useful debug information.
The patch itself is fine and worthy of a reviewed-by, there is just one
nearby bug that may as well be squashed in with this cleanup...
> ---
> drivers/gpu/drm/i915/i915_debugfs.c | 16 ++++++++++------
> drivers/gpu/drm/i915/i915_drv.h | 7 +++++--
> drivers/gpu/drm/i915/i915_irq.c | 9 +++++++--
> drivers/gpu/drm/i915/i915_reg.h | 3 +++
> 4 files changed, 25 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_debugfs.c b/drivers/gpu/drm/i915/i915_debugfs.c
> index d618f78..5f5eb5b 100644
> --- a/drivers/gpu/drm/i915/i915_debugfs.c
> +++ b/drivers/gpu/drm/i915/i915_debugfs.c
> @@ -734,17 +734,21 @@ static void i915_ring_error_state(struct seq_file *m,
> unsigned ring)
> {
> seq_printf(m, "%s command stream:\n", ring_str(ring));
> + seq_printf(m, " HEAD: 0x%08x\n", error->head[ring]);
> + seq_printf(m, " TAIL: 0x%08x\n", error->tail[ring]);
> seq_printf(m, " ACTHD: 0x%08x\n", error->acthd[ring]);
> seq_printf(m, " IPEIR: 0x%08x\n", error->ipeir[ring]);
> seq_printf(m, " IPEHR: 0x%08x\n", error->ipehr[ring]);
> seq_printf(m, " INSTDONE: 0x%08x\n", error->instdone[ring]);
> - if (ring == RCS) {
> - if (INTEL_INFO(dev)->gen >= 4) {
> - seq_printf(m, " INSTDONE1: 0x%08x\n", error->instdone1);
> - seq_printf(m, " INSTPS: 0x%08x\n", error->instps);
> - }
> - seq_printf(m, " INSTPM: 0x%08x\n", error->instpm);
> + if (ring == RCS && INTEL_INFO(dev)->gen >= 4) {
> + seq_printf(m, " INSTDONE1: 0x%08x\n", error->instdone1);
> + seq_printf(m, " BBADDR: 0x%08llx\n", error->bbaddr);
> }
> + if (INTEL_INFO(dev)->gen >= 4)
> + seq_printf(m, " INSTPS: 0x%08x\n", error->instps[ring]);
> + seq_printf(m, " INSTPM: 0x%08x\n", error->instpm[ring]);
> + if (INTEL_INFO(dev)->gen >= 6)
> + seq_printf(m, " FADDR: 0x%08x\n", error->faddr[ring]);
> seq_printf(m, " seqno: 0x%08x\n", error->seqno[ring]);
> }
>
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index 5f3ff9d..3701369 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -149,16 +149,19 @@ struct drm_i915_error_state {
> u32 eir;
> u32 pgtbl_er;
> u32 pipestat[I915_MAX_PIPES];
> + u32 tail[I915_NUM_RINGS];
> + u32 head[I915_NUM_RINGS];
> u32 ipeir[I915_NUM_RINGS];
> u32 ipehr[I915_NUM_RINGS];
> u32 instdone[I915_NUM_RINGS];
> u32 acthd[I915_NUM_RINGS];
> u32 error; /* gen6+ */
> - u32 instpm;
> - u32 instps;
> + u32 instpm[I915_NUM_RINGS];
> + u32 instps[I915_NUM_RINGS];
> u32 instdone1;
> u32 seqno[I915_NUM_RINGS];
> u64 bbaddr;
> + u32 faddr[I915_NUM_RINGS];
> u64 fence[16];
> struct timeval time;
> struct drm_i915_error_object {
> diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
> index 79aba7f..ea1721f 100644
> --- a/drivers/gpu/drm/i915/i915_irq.c
> +++ b/drivers/gpu/drm/i915/i915_irq.c
> @@ -878,12 +878,15 @@ static void i915_record_ring_state(struct drm_device *dev,
> {
> struct drm_i915_private *dev_priv = dev->dev_private;
>
> + if (INTEL_INFO(dev)->gen >= 6)
> + error->faddr[ring->id] = I915_READ(RING_DMA_FADD(ring->mmio_base));
> +
> if (INTEL_INFO(dev)->gen >= 4) {
> error->ipeir[ring->id] = I915_READ(RING_IPEIR(ring->mmio_base));
> error->ipehr[ring->id] = I915_READ(RING_IPEHR(ring->mmio_base));
> error->instdone[ring->id] = I915_READ(RING_INSTDONE(ring->mmio_base));
> + error->instps[ring->id] = I915_READ(RING_INSTPS(ring->mmio_base));
> if (ring->id == RCS) {
> - error->instps = I915_READ(INSTPS);
> error->instdone1 = I915_READ(INSTDONE1);
> error->bbaddr = I915_READ64(BB_ADDR);
> }
> @@ -894,8 +897,11 @@ static void i915_record_ring_state(struct drm_device *dev,
> error->bbaddr = 0;
> }
>
> + error->instpm[ring->id] = I915_READ(RING_INSTPM(ring->mmio_base));
> error->seqno[ring->id] = dev_priv->ring->get_seqno(ring);
Whilst you are here, you may as well fix this ^.
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
^ permalink raw reply
* Re: [PATCH] drm/i915: collect more per ring error state
From: Chris Wilson @ 2011-10-30 18:46 UTC (permalink / raw)
To: intel-gfx; +Cc: Daniel Vetter
In-Reply-To: <e39f63$2g7kbb@fmsmga002.fm.intel.com>
On Sun, 30 Oct 2011 18:39:03 +0000, Chris Wilson <chris@chris-wilson.co.uk> wrote:
> On Tue, 11 Oct 2011 21:20:21 +0200, Daniel Vetter <daniel.vetter@ffwll.ch> wrote:
> > Based on a patch by Ben Widawsky, but with different colors
> > for the bikeshed.
> >
> > In contrast to Ben's patch this one doesn't add the fault regs.
> > Afaics they're for the optional page fault support which
> > - we're not enabling
> > - and which seems to be unsupported by the hw team. Recent bspec
> > lacks tons of information about this that the public docs released
> > half a year back still contain.
> >
> > Also dump ring HEAD/TAIL registers - I've recently seen a few
> > error_state where just guessing these is not good enough.
> >
> > v2: Also dump INSTPM for every ring.
> >
> > v3: Fix a few really silly goof-ups spotted by Chris Wilson.
> >
> > Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
>
> This is independent of the "hangcheck robustification" (which I feel is
> false advertising ;-) and adds some mildly useful debug information.
> The patch itself is fine and worthy of a reviewed-by, there is just one
> nearby bug that may as well be squashed in with this cleanup...
>
> > ---
> > drivers/gpu/drm/i915/i915_debugfs.c | 16 ++++++++++------
> > drivers/gpu/drm/i915/i915_drv.h | 7 +++++--
> > drivers/gpu/drm/i915/i915_irq.c | 9 +++++++--
> > drivers/gpu/drm/i915/i915_reg.h | 3 +++
> > 4 files changed, 25 insertions(+), 10 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/i915_debugfs.c b/drivers/gpu/drm/i915/i915_debugfs.c
> > index d618f78..5f5eb5b 100644
> > --- a/drivers/gpu/drm/i915/i915_debugfs.c
> > +++ b/drivers/gpu/drm/i915/i915_debugfs.c
> > @@ -734,17 +734,21 @@ static void i915_ring_error_state(struct seq_file *m,
> > unsigned ring)
> > {
> > seq_printf(m, "%s command stream:\n", ring_str(ring));
> > + seq_printf(m, " HEAD: 0x%08x\n", error->head[ring]);
> > + seq_printf(m, " TAIL: 0x%08x\n", error->tail[ring]);
> > seq_printf(m, " ACTHD: 0x%08x\n", error->acthd[ring]);
> > seq_printf(m, " IPEIR: 0x%08x\n", error->ipeir[ring]);
> > seq_printf(m, " IPEHR: 0x%08x\n", error->ipehr[ring]);
> > seq_printf(m, " INSTDONE: 0x%08x\n", error->instdone[ring]);
> > - if (ring == RCS) {
> > - if (INTEL_INFO(dev)->gen >= 4) {
> > - seq_printf(m, " INSTDONE1: 0x%08x\n", error->instdone1);
> > - seq_printf(m, " INSTPS: 0x%08x\n", error->instps);
> > - }
> > - seq_printf(m, " INSTPM: 0x%08x\n", error->instpm);
> > + if (ring == RCS && INTEL_INFO(dev)->gen >= 4) {
> > + seq_printf(m, " INSTDONE1: 0x%08x\n", error->instdone1);
> > + seq_printf(m, " BBADDR: 0x%08llx\n", error->bbaddr);
> > }
> > + if (INTEL_INFO(dev)->gen >= 4)
> > + seq_printf(m, " INSTPS: 0x%08x\n", error->instps[ring]);
> > + seq_printf(m, " INSTPM: 0x%08x\n", error->instpm[ring]);
> > + if (INTEL_INFO(dev)->gen >= 6)
> > + seq_printf(m, " FADDR: 0x%08x\n", error->faddr[ring]);
> > seq_printf(m, " seqno: 0x%08x\n", error->seqno[ring]);
> > }
> >
> > diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> > index 5f3ff9d..3701369 100644
> > --- a/drivers/gpu/drm/i915/i915_drv.h
> > +++ b/drivers/gpu/drm/i915/i915_drv.h
> > @@ -149,16 +149,19 @@ struct drm_i915_error_state {
> > u32 eir;
> > u32 pgtbl_er;
> > u32 pipestat[I915_MAX_PIPES];
> > + u32 tail[I915_NUM_RINGS];
> > + u32 head[I915_NUM_RINGS];
> > u32 ipeir[I915_NUM_RINGS];
> > u32 ipehr[I915_NUM_RINGS];
> > u32 instdone[I915_NUM_RINGS];
> > u32 acthd[I915_NUM_RINGS];
> > u32 error; /* gen6+ */
> > - u32 instpm;
> > - u32 instps;
> > + u32 instpm[I915_NUM_RINGS];
> > + u32 instps[I915_NUM_RINGS];
> > u32 instdone1;
> > u32 seqno[I915_NUM_RINGS];
> > u64 bbaddr;
> > + u32 faddr[I915_NUM_RINGS];
> > u64 fence[16];
> > struct timeval time;
> > struct drm_i915_error_object {
> > diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
> > index 79aba7f..ea1721f 100644
> > --- a/drivers/gpu/drm/i915/i915_irq.c
> > +++ b/drivers/gpu/drm/i915/i915_irq.c
> > @@ -878,12 +878,15 @@ static void i915_record_ring_state(struct drm_device *dev,
> > {
> > struct drm_i915_private *dev_priv = dev->dev_private;
> >
> > + if (INTEL_INFO(dev)->gen >= 6)
> > + error->faddr[ring->id] = I915_READ(RING_DMA_FADD(ring->mmio_base));
> > +
> > if (INTEL_INFO(dev)->gen >= 4) {
> > error->ipeir[ring->id] = I915_READ(RING_IPEIR(ring->mmio_base));
> > error->ipehr[ring->id] = I915_READ(RING_IPEHR(ring->mmio_base));
> > error->instdone[ring->id] = I915_READ(RING_INSTDONE(ring->mmio_base));
> > + error->instps[ring->id] = I915_READ(RING_INSTPS(ring->mmio_base));
> > if (ring->id == RCS) {
> > - error->instps = I915_READ(INSTPS);
> > error->instdone1 = I915_READ(INSTDONE1);
> > error->bbaddr = I915_READ64(BB_ADDR);
> > }
> > @@ -894,8 +897,11 @@ static void i915_record_ring_state(struct drm_device *dev,
> > error->bbaddr = 0;
> > }
> >
> > + error->instpm[ring->id] = I915_READ(RING_INSTPM(ring->mmio_base));
> > error->seqno[ring->id] = dev_priv->ring->get_seqno(ring);
> Whilst you are here, you may as well fix this ^.
Daniel pointed out that I already reviewed a patch to fix this, so I
hereby review this patch to add the extra debug information!
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
^ permalink raw reply
* [PATCH] mach-ixp4xx: made gpio functions atomic
From: Russell King - ARM Linux @ 2011-10-30 18:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1319973693-19063-1-git-send-email-fransmeulenbroeks@gmail.com>
On Sun, Oct 30, 2011 at 12:21:33PM +0100, Frans Meulenbroeks wrote:
> gpio_line_set and gpio_line config on ixp4xx were not atomic
> This patch fixes this by surrounding them with local_irq_save and
> local_irq_restore calls, similar to the way Lennert Buytenhek
> implemented this for iop. (see arch/arm/plat-iop/gpio.c)
>
> Signed-off-by: Frans Meulenbroeks <fransmeulenbroeks@gmail.com>
> ---
>
> Note: an alternative solution would be to use the set_bit and
> clear_bit atomic functions, but I felt it better to do things
> the same way as Lennert did. Also it could be that this is a few
> bytes smaller. Didn't check that.
set_bit and clear_bit should not be used on IO memory - on ARMv6 and
later these use the load exclusive/store exclusive operations which
are only valid on 'normal memory' mappings and not 'device' mappings.
Plus of course, IO memory is supposed to be __iomem and accessed using
the proper accessors, and using set_bit and clear_bit on such pointers
will issue sparse warnings.
^ permalink raw reply
* Re: [dm-crypt] please HELP - can't acces encrypted LVM after linux reinstallation.
From: Aleksander Swirski @ 2011-10-30 18:56 UTC (permalink / raw)
To: dm-crypt
In-Reply-To: <20111030173230.GA31497@tansi.org>
[-- Attachment #1: Type: text/plain, Size: 5036 bytes --]
Arno, I'm glad that this info will be now in the FAQ. About my system being
sound - can't quite agree on that. Just got a tiny little bit of luck in
this unlucky situation. My habit of always writing some most important
passwords by hand, made all the difference between 'disaster' and
'apocalypse' :)
I will also try to push this info to the debian devs. I'm not sure how to do
that properly (hint appreciated). I know, that the route of installation I
took is not a common one, but a simple warning would suffice to avoid this
kind of trouble. After all my encrypted LVM and specifically the /home
partition within LVM wasn't listed among those, which are to be erased at
any point during the installation. (I marked them with - K - keep the data)
On 30 October 2011 18:32, Arno Wagner <arno@wagner.name> wrote:
> On Sun, Oct 30, 2011 at 05:08:08PM +0100, Aleksander Swirski wrote:
> > I fully agree. I managed to retrieve all crucial passwords (fortunately I
> > remembered most of them and was able to reset the rest). The web pages I
> > was working with are on servers, and many materials in my e-mail history.
> > Older documents and most of the photos on some DVD's. After initial shock
> > now I accept what has happened and I decided to work on my personality to
> > change attitude towards taking unnecessary risk. There is no place for
> that
> > if I want to be professional in what I do.
>
> Indeed. But is is a learning process.
>
> > I think this is a good idea, to try to put the message through,
> especially
> > to less knowledgeable users, about the loose nature of the relationship
> > between the pass phrase and the real cryptographic key, which does the
> > whole job underneath.
>
> Added to the FAQ, currently on the web, to be posted here
> next week. And that you managed to get the most critical data
> back means your system is essentially sound.
>
> Arno
>
>
> > Thanks to all.
> >
> > On 29 October 2011 09:43, Arno Wagner <arno@wagner.name> wrote:
> >
> > > You are welcome. And you learned something valuable, I doubt this
> > > will ever happen to you again. In fact I learned to be careful
> > > with a similar experience (no crypto involved though). I think
> > > you will find that most people have learned to be careful with
> > > data in some similar way. So don't feel to bad about it.
> > >
> > > Arno
> > >
> > > On Sat, Oct 29, 2011 at 07:14:27AM +1300, Aleksander Swirski wrote:
> > > > it's my largest drive, but I will put this one aside and use another
> > > > computer. i was tired, when i did that, didn't have clear mind. now I
> > > have
> > > > no idea, how possibly could I fix this, but it all happened because
> of
> > > some
> > > > mental pressure I felt. so I guess, now it's time to chill out.
> anyway, i
> > > > feel bit better because You People :) cared enough to inform me and
> > > tried to
> > > > help me. it's greatly appreciated.
> > > >
> > > > On 29 October 2011 06:20, Heinz Diehl <htd@fancy-poultry.org> wrote:
> > > >
> > > > > On 28.10.2011, Aleksander Swirski wrote:
> > > > >
> > > > > > i made big mistake. at least I have plenty of space now ...
> > > > >
> > > > > Maybe, maybe not. I would strongly suggest that you make a low
> level
> > > > > backup of your whole disk. Maybe there is something you didn't
> think
> > > > > about right now, which suddenly comes up after a few days or
> weeks...
> > > > >
> > > > > _______________________________________________
> > > > > dm-crypt mailing list
> > > > > dm-crypt@saout.de
> > > > > http://www.saout.de/mailman/listinfo/dm-crypt
> > > > >
> > >
> > > > _______________________________________________
> > > > dm-crypt mailing list
> > > > dm-crypt@saout.de
> > > > http://www.saout.de/mailman/listinfo/dm-crypt
> > >
> > >
> > > --
> > > Arno Wagner, Dr. sc. techn., Dipl. Inform., CISSP -- Email:
> > > arno@wagner.name
> > > GnuPG: ID: 1E25338F FP: 0C30 5782 9D93 F785 E79C 0296 797F 6B50 1E25
> > > 338F
> > > ----
> > > Cuddly UI's are the manifestation of wishful thinking. -- Dylan Evans
> > >
> > > If it's in the news, don't worry about it. The very definition of
> > > "news" is "something that hardly ever happens." -- Bruce Schneier
> > > _______________________________________________
> > > dm-crypt mailing list
> > > dm-crypt@saout.de
> > > http://www.saout.de/mailman/listinfo/dm-crypt
> > >
>
> > _______________________________________________
> > dm-crypt mailing list
> > dm-crypt@saout.de
> > http://www.saout.de/mailman/listinfo/dm-crypt
>
>
> --
> Arno Wagner, Dr. sc. techn., Dipl. Inform., CISSP -- Email:
> arno@wagner.name
> GnuPG: ID: 1E25338F FP: 0C30 5782 9D93 F785 E79C 0296 797F 6B50 1E25
> 338F
> ----
> Cuddly UI's are the manifestation of wishful thinking. -- Dylan Evans
>
> If it's in the news, don't worry about it. The very definition of
> "news" is "something that hardly ever happens." -- Bruce Schneier
> _______________________________________________
> dm-crypt mailing list
> dm-crypt@saout.de
> http://www.saout.de/mailman/listinfo/dm-crypt
>
[-- Attachment #2: Type: text/html, Size: 7070 bytes --]
^ permalink raw reply
* Re: [PATCH 1/2] add boot_config command support
From: Jean-Christophe PLAGNIOL-VILLARD @ 2011-10-30 18:50 UTC (permalink / raw)
To: Sascha Hauer; +Cc: barebox
In-Reply-To: <20111028221922.GF23421@pengutronix.de>
> > + dev = "sda1";
> > + fs = "ext3";
> > + path = "/boot/inird-3.0.0";
> > + };
> > + fdt@3 {
> > + dev = "sda1";
> > + fs = "ext3";
> > + path = "boot/usb_a9g20.dtb";
> > + };
> > +
> > + kernel@4 {
> > + format = "uimage";
> > + dev = "sda3";
> > + fs = "squashfs";
> > + path = "/boot/uImage-installer-3.0.0";
> > + };
> > + initrd@4 {
> > + dev = "sda3";
> > + fs = "squashfs";
> > + path = "/boot/initrd-installer-3.0.0";
> > + };
>
> Why do you describe the device/fstype in each and every node? a
> reference to a partition descriptions would be more convenient here.
> Also it's strange that the patch is an absolute path and not a path
> relative to the mountpoint.
becasue we need to known the fs to mont it
the fs could a real fs or nfs or tftp the path is absolute mount the
mountpoint
>
> > + };
> > +
> > + configuration {
> > + description = "Welcome on Barebox Boot Sequence";
> > + default = "linux_3_0_0";
> > + altboot = "installer";
> > + bootdelay = <5>;
> > + splash = /incbin/("splash_menu.bmp");
> > +
> > + linux_2_6_36 {
> > + description = "Linux 2.6.36";
> > + cmdline = "mem=64M console=ttyS0,115200 root=/dev/sda2 rw rootfstype=ext3";
>
> We should be able to build the commandline out of its parts. A
> monolithic string seems not very flexible.
the idea is to put var inside and after you will use this cmdline as a based
to construct the finall one
>
> > + kernel = "kernel@1";
> > + initrd = "initrd@1";
> phandles instead?
>
more code in the c code and mre difficult to handle when modifying the dtb
from barebox
>
> > + description = "Installer Linux 3.0.0";
> > + cmdline = "mem=64M console=ttyS0,115200 root=/dev/sda4 ro rootfstype=squashfs";
> > + splash = /incbin/("splash_installer.bmp");
> > + kernel = "kernel@4";
> > + initrd = "initrd@4";
> > + };
> > +
> > +#define OPTS "f:dlc:b:"
>
> This is used only once. It would be clearer to just use the string
> instead.
as done on menu framework we will have tehe management part so 2 OPTS
the code is not finished or even enough advanced to publixh it
>
> > +
> > +static void print_entries(void)
> > +{
> > + struct boot_config_data *bed;
> > +
> > + printf("[Kernel]\n");
> > +
> > + list_for_each_entry(bed, boot_config_get_kernels(), list)
> > + printf("%s\n", bed->name);
>
> So instead of the list_head directly you export it via
> boot_config_get_kernels() which basically has the same effect but is
> harder to read. Please do not do that.
realy don't like to export it
>
> > + printf("[Initrd]\n");
> > +
> > + list_for_each_entry(bed, boot_config_get_initrds(), list)
> > + printf("%s\n", bed->name);
> > +
> > + printf("[FDT]\n");
> > +
> > + list_for_each_entry(bed, boot_config_get_fdts(), list)
> > + printf("%s\n", bed->name);
> > +
> > +}
> > +
> > +static void print_boot_config_data(struct boot_config_data *bed)
>
> What's a bed? Supposedly the thing I should go now.
I like it :P
it was supposed to mean boot env data
but switch to boot_config_data
>
> > +{
> > + printf("name = '%s'\n", bed->name);
> > + printf("dev = '%s'\n", bed->dev);
> > + printf("fs = '%s'\n", bed->fs);
> > + printf("path = '%s'\n", bed->path);
> > +}
> > +
> > +static void print_boot_config(struct boot_config *e)
> > +{
> > + struct boot_config_var *v;
> > +
> > + printf("Config '%s'\n\n", e->name);
> > +
> > + v = boot_config_var_get_by_name(e, "description");
>
> You have a mechanism to attach arbitrary key/value pairs to a struct
> boot_config. Still you do not iterate over all over all variables in the
> corresponding devicetree node, but instead only handle the variables
> explicitely that you now about.
>
> This does not make sense. struct boot_config should simply have a char
> *description, char *cmdline and whatever else you need. Then you can
> remove this boot_config_var_get_by_name() cruft.
I knwon this version is not switch to new one I finish it
>
> > + printf("description = %s\n", v->value);
> > + v = boot_config_var_get_by_name(e, "cmdline");
> > + printf("cmdline = '%s'\n", v->value);
> > + v = boot_config_var_get_by_name(e, "splash");
> > + if (v)
> > + printf("splash = '%s'\n", v->value);
> > +
> > + printf("[Kernel]\n");
> > + print_boot_config_data(e->kernel);
> > +
> > + if (e->initrd) {
> > + printf("[Initrd]\n");
> > + print_boot_config_data(e->initrd);
> > + }
> > +
> > + if (e->fdt) {
> > + printf("[fdt]\n");
> > + print_boot_config_data(e->fdt);
> > + }
> > +}
> > +
> > +/*
> > + * boot_config -l [-c config]
> > + */
>
> [...]
>
> > +
> > +static int do_boot_config(struct command *cmdtp, int argc, char *argv[])
> > +{
> > + struct cmd_bood_config cbc;
> > + int opt;
> > + int ret = COMMAND_ERROR_USAGE;
> > +
> > + memset(&cbc, 0, sizeof(struct cmd_bood_config));
> > +
> > + while((opt = getopt(argc, argv, OPTS)) > 0) {
> > + switch(opt) {
> > + case 'f':
> > + cbc.action = action_load;
> > + cbc.filename = optarg;
> > + break;
> > + case 'd':
> > + boot_config_unload();
> > + break;
> > + case 'l':
> > + cbc.action = action_list;
> > + break;
> > + case 'b':
> > + cbc.action = action_boot;
> > + case 'c':
> > + cbc.config = optarg;
> > + break;
> > + }
> > + }
> > +
> > + switch(cbc.action) {
>
> What's this cbc.action thing about? It is only ever used in this
> function.
is to specify what to do based on the option as you can have alots of option
see menu framwork
>
> > + case action_list:
> > + ret = do_boot_config_list(&cbc);
> > + break;
> > + case action_load:
> > + ret = do_boot_config_load(&cbc);
> > + break;
> > + case action_boot:
> > + ret = do_boot_config_boot(&cbc);
> > + break;
> > +
> > + };
> > +
> > + if (ret)
> > + return COMMAND_ERROR_USAGE;
>
> I don't know what errors you expect from above, but for sure it does not
> necessarily mean that it's a usage error.
>
> > +
> > + return 0;
> > +}
> > +
>
> [,..]
>
> >
> > diff --git a/common/boot_config.c b/common/boot_config.c
> > new file mode 100644
> > index 0000000..b60ce26
> > --- /dev/null
> > +
> > +struct list_head* boot_config_get_fdts(void)
> > +{
> > + return &fdts;
> > +}
>
> So much code just to handle some global data. You should collect this in
> a struct and pass it around where you need it instead,
>
> > +
> +
> > + if (initrd) {
> > + ret = boot_config_var_add(e, "initrd", initrd);
> > + if (ret)
> > + goto err_free;
> > + }
> > +
> > + if (fdt) {
> > + ret = boot_config_var_add(e, "fdt", fdt);
> > + if (ret)
> > + goto err_free;
> > + }
>
> I am not going to read further. Every struct boot_config seems to have a
> clearly defined set of variables but instead of adding the corresponding
> pointers to struct boot_config you have this strange
> attach-key-value-pairs-to-c-struct in place.
> Supposedly this is some leftover from earlier versions. Sending
> non-finished patches as a RFC is perfectly fine, but in this case it's
> sometimes really hard to see where you're heading to.
Yas you have miniamal set of variable but the code is more generic and
support to have more var.
As example for network or complex system the idea is to have no limit of which
var you can add, you just need to specify the mandatory one.
And the Framework is not DTB only but generic other format will have other
var.
>
> If you want to get this in someday it's going to be a long way.
> Communicating with the Linux userspace using a devicetree means creating
> an API which also means that we have to have the nice feeling that this API
> can be stable. Right now it more looks to me as if the devicetree format is
> an adhoc implementation of what you needed for your example.
The point is the DTB is one format , we can use ant format for the
boot_config.
THe DTB match the need to describe the boot config and will not impact the
boot laoder size but we can use a grub config file too or PXE boot
so the DTB is just a format to support to demonstrate the boot_config
framework
Best Regards,
J.
_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox
^ permalink raw reply
* Re: [PATCH 2/2] gitweb: add a feature to show side-by-side diff
From: Jakub Narebski @ 2011-10-30 18:56 UTC (permalink / raw)
To: Kato Kazuyoshi; +Cc: git, Jakub Narebski
In-Reply-To: <CAFo4x0L4BAKnCDa1uEK0Rskd9kTsR-94D4mkYKnLGqVDnuyuBA@mail.gmail.com>
Those are additional comments, most of which I have come about when
rewriting this series and testing it.
There are to complement existing comments in other post(s).
Kato Kazuyoshi <kato.kazuyoshi@gmail.com> writes:
> ---
> gitweb/gitweb.perl | 81 +++++++++++++++++++++++++++++++++++++++++----
> gitweb/static/gitweb.css | 15 ++++++++
> 2 files changed, 88 insertions(+), 8 deletions(-)
No tests.
> diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
> index 095adda..dca09dc 100755
> --- a/gitweb/gitweb.perl
> +++ b/gitweb/gitweb.perl
> @@ -757,6 +757,7 @@ our @cgi_param_mapping = (
> extra_options => "opt",
> search_use_regexp => "sr",
> ctag => "by_tag",
> + diff_style => "ds",
> # this must be last entry (for manipulation from JavaScript)
> javascript => "js"
> );
Alternate solution would be to use 'extra_options' ("opt") for
that... though current use of it in gitweb seems to suggest that it is
more about passing extra options to underlying git commands; and "git
diff" doesn't support '--side-by-side' like GNU diff does, (yet?).
So currently I favor neither.
> @@ -1072,6 +1073,8 @@ sub evaluate_and_validate_params {
> }
> $search_regexp = $search_use_regexp ? $searchtext : quotemeta $searchtext;
> }
> +
> + $input_params{diff_style} ||= 'inline';
> }
Hmmm... similar option 'order' ("o") had default value set in action
subroutine. I wonder if it wouldn't be better to do the same also in
this situation.
> @@ -2276,7 +2279,7 @@ sub format_diff_line {
> }
> $line = "<span class=\"chunk_info\">@@ $from_text $to_text @@</span>" .
> "<span class=\"section\">" . esc_html($section, -nbsp=>1) .
> "</span>";
> - return "$div_open$line</div>\n";
> + return $diff_class, "$div_open$line</div>\n";
> } elsif ($from && $to && $line =~ m/^\@{3}/) {
> my ($prefix, $ranges, $section) = $line =~ m/^(\@+) (.*?) \@+(.*)$/;
> my (@from_text, @from_start, @from_nlines, $to_text, $to_start, $to_nlines);
This subroutine no longer *format* line to be printed, isn't it?
> @@ -4828,8 +4831,32 @@ sub git_difftree_body {
> print "</table>\n";
> }
>
> +sub format_diff_chunk {
Name: it is not about diff chunk (or hunk), but about a block of lines
in a chunk; in this case block of change lines (rem / add). Also, it
is not about generic diff, only about sidebyside one.
BTW. I think it would be better if this subroutine also managed
context lines.
> + my @chunk = @_;
> +
> + my $first_class = $chunk[0]->[0];
Style: You can use simply $chunk[0][0] here. perlref(1) says:
"The arrow is optional between brackets subscripts, [...]"
> + my @partial = map { $_->[1] } grep { $_->[0] eq $first_class } @chunk;
> +
> + if (scalar @partial < scalar @chunk) {
Style: you can write simply
+ if (@partial < @chunk) {
> + return join '', ("<div class='chunk'><div class='old'>",
> + @partial,
> + "</div>",
> + "<div class='new'>",
> + (map {
> + $_->[1];
> + } @chunk[scalar @partial..scalar @chunk-1]),
> + "</div></div>");
> + } else {
> + return join '', ("<div class='chunk'><div class='",
> + ($first_class eq 'add' ? 'new' : 'old'),
> + "'>",
> + @partial,
> + "</div></div>");
> + }
> +}
Anyway this code is not very clear. You rely on the fact that if
there are two classes, then they are "rem" first, and "add" second.
Also, it is I think overly complicated.
> +
> sub git_patchset_body {
> - my ($fd, $difftree, $hash, @hash_parents) = @_;
> + my ($fd, $is_inline, $difftree, $hash, @hash_parents) = @_;
Rather than passing $is_inline, I think it would be better to pass
$diff_style (with default value filled in)
> my ($hash_parent) = $hash_parents[0];
>
> my $is_combined = (@hash_parents > 1);
> @@ -4940,12 +4967,31 @@ sub git_patchset_body {
>
> # the patch itself
> LINE:
> + my @chunk;
> while ($patch_line = <$fd>) {
> chomp $patch_line;
>
> next PATCH if ($patch_line =~ m/^diff /);
Here is a bug. If patchset consists of more than one patch, if
not-last patches have change that does not have trailing context lines
(changed, added or removed lines at the end of file), then the last
block will be lost (@chunk can be non-empty here).
>
> - print format_diff_line($patch_line, \%from, \%to);
> + my ($class, $line) = format_diff_line($patch_line, \%from, \%to);
> + if ($is_inline) {
That is wrong to test for. You should test if you can use
side-by-side diff, not if you use default output.
Especially that diff can be combined diff of a merge commit, which
cannot be represented as 2-sided side-by-side diff; for such diff
gitweb needs to use inline diff.
> + print $line;
> + } elsif ($class eq 'add' || $class eq 'rem') {
> + push @chunk, [ $class, $line ];
> + } else {
> + if (@chunk) {
> + print format_diff_chunk(@chunk);
> + @chunk = ();
> + } elsif ($class eq 'chunk_header') {
> + print $line;
> + } else {
> + print '<div class="chunk"><div class="old">',
> + $line,
> + '</div><div class="new">',
> + $line,
> + '</div></div>';
All of this should in my opinion be done in format_diff_chunk(), not
in caller. This also introduces a bit of inconsistency in that
added/removed lines are in single block and context lines are each in
its own block.
Additionally you forgot about incomplete lines here, which can apply
either to added lines, removed lines, both of added and removed lines,
and to context lines. Your code generates incorrect info in the case
if incomplete line is either removed line only, or added line only.
[Nb. I have to check my code yet again.]
> +sub diff_nav {
> + my ($style) = @_;
> +
> + my %pairs = (inline => 'inline', 'sidebyside' => 'side by side');
> + join '', ($cgi->start_form({ method => 'get' }),
> + $cgi->hidden('p'),
> + $cgi->hidden('a'),
> + $cgi->hidden('h'),
> + $cgi->hidden('hp'),
> + $cgi->hidden('hb'),
> + $cgi->hidden('hpb'),
> + $cgi->popup_menu('ds', [keys %pairs], $style, \%pairs),
> + $cgi->submit('change'),
> + $cgi->end_form);
> +}
What about 'f' and 'fp' for "blobdiff" view?
> diff --git a/gitweb/static/gitweb.css b/gitweb/static/gitweb.css
> index 7d88509..dc84db2 100644
> --- a/gitweb/static/gitweb.css
> +++ b/gitweb/static/gitweb.css
> @@ -618,6 +618,21 @@ div.remote {
> cursor: pointer;
> }
>
> +/* side-by-side diff */
> +div.chunk {
> + overflow: hidden;
> +}
> +
> +div.chunk div.old {
> + float: left;
> + width: 50%;
> + overflow: hidden;
> +}
> +
> +div.chunk div.new {
> + margin-left: 50%;
> + width: 50%;
> +}
Nice trick of composing CSS layout... though I wonder if there is
perhaps a better solution.
Anyway, I think this addition should be put near style for div.diff
etc.
--
Jakub Narębski
^ permalink raw reply
* Compat-wireless release for 2011-10-30 is baked
From: Compat-wireless cronjob account @ 2011-10-30 19:02 UTC (permalink / raw)
To: linux-wireless
compat-wireless code metrics
814862 - Total upstream lines of code being pulled
2431 - backport code changes
2113 - backport code additions
318 - backport code deletions
8588 - backport from compat module
11019 - total backport code
1.3523 - % of code consists of backport work
^ permalink raw reply
* Re: [dm-crypt] please HELP - can't acces encrypted LVM after linux reinstallation.
From: Aleksander Swirski @ 2011-10-30 19:03 UTC (permalink / raw)
To: dm-crypt
In-Reply-To: <1319876133.21316.3.camel@scapa>
[-- Attachment #1: Type: text/plain, Size: 1403 bytes --]
This was always decrypted data. I was making tar archives of system
partitions, already decrypted and mounted. So I think, the header can't be
there?
Yves, looking at your e-mail - maybe you can advice me weather and how
should I send some info to debian team? I think some small warning or info
could make a big difference for other people who might try to reattach their
previously encrypted drive to a new debian install.
On 29 October 2011 10:15, Yves-Alexis Perez <corsac@debian.org> wrote:
> On sam., 2011-10-29 at 07:14 +1300, Aleksander Swirski wrote:
> > it's my largest drive, but I will put this one aside and use another
> > computer. i was tired, when i did that, didn't have clear mind. now I
> have
> > no idea, how possibly could I fix this, but it all happened because of
> some
> > mental pressure I felt. so I guess, now it's time to chill out. anyway, i
> > feel bit better because You People :) cared enough to inform me and tried
> to
> > help me. it's greatly appreciated.
>
> You said in the initial mail that you had some backup of the system but
> they were a bit old. Are those backup of encrypted or decrypted data? Is
> there a chance you may have the luks header somehwere in your backups?
>
> Regards,
> --
> Yves-Alexis
>
> _______________________________________________
> dm-crypt mailing list
> dm-crypt@saout.de
> http://www.saout.de/mailman/listinfo/dm-crypt
>
>
[-- Attachment #2: Type: text/html, Size: 1905 bytes --]
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
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.