Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1261858 > unrolled thread

[RFC PATCH 00/28] Linux Kernel Library

Started byOctavian Purdila <octavian.purdila@intel.com>
First post2015-11-03 21:30 +0100
Last post2015-11-08 14:50 +0100
Articles 20 on this page of 42 — 7 participants

Back to article view | Back to linux.kernel

Contents

  [RFC PATCH 00/28] Linux Kernel Library Octavian Purdila <octavian.purdila@intel.com> - 2015-11-03 21:30 +0100
    [RFC PATCH 21/28] lkl tools: host lib: posix host operations Octavian Purdila <octavian.purdila@intel.com> - 2015-11-03 21:30 +0100
      Re: [RFC PATCH 21/28] lkl tools: host lib: posix host operations Arnd Bergmann <arnd@arndb.de> - 2015-11-08 00:20 +0100
        Re: [RFC PATCH 21/28] lkl tools: host lib: posix host operations Octavian Purdila <octavian.purdila@intel.com> - 2015-11-08 05:10 +0100
          Re: [RFC PATCH 21/28] lkl tools: host lib: posix host operations Arnd Bergmann <arnd@arndb.de> - 2015-11-08 11:40 +0100
    [RFC PATCH 18/28] lkl tools: host lib: virtio devices Octavian Purdila <octavian.purdila@intel.com> - 2015-11-03 21:30 +0100
    [RFC PATCH 19/28] lkl tools: host lib: virtio block device Octavian Purdila <octavian.purdila@intel.com> - 2015-11-03 21:30 +0100
      Re: [RFC PATCH 19/28] lkl tools: host lib: virtio block device Richard Weinberger <richard.weinberger@gmail.com> - 2015-11-07 13:30 +0100
        Re: [RFC PATCH 19/28] lkl tools: host lib: virtio block device Octavian Purdila <octavian.purdila@intel.com> - 2015-11-08 05:20 +0100
          Re: [RFC PATCH 19/28] lkl tools: host lib: virtio block device Richard Weinberger <richard@nod.at> - 2015-11-08 14:40 +0100
    [RFC PATCH 13/28] lkl: initialization and cleanup Octavian Purdila <octavian.purdila@intel.com> - 2015-11-03 21:30 +0100
    [RFC PATCH 20/28] lkl tools: host lib: filesystem helpers Octavian Purdila <octavian.purdila@intel.com> - 2015-11-03 21:30 +0100
    [RFC PATCH 24/28] lkl tools: tool that reads/writes to/from a filesystem image Octavian Purdila <octavian.purdila@intel.com> - 2015-11-03 21:30 +0100
    [RFC PATCH 22/28] lkl tools: "boot" test Octavian Purdila <octavian.purdila@intel.com> - 2015-11-03 21:30 +0100
    [RFC PATCH 02/28] kbuild: allow architectures to automatically define kconfig symbols Octavian Purdila <octavian.purdila@intel.com> - 2015-11-03 21:30 +0100
    [RFC PATCH 17/28] lkl tools: host lib: memory mapped I/O helpers Octavian Purdila <octavian.purdila@intel.com> - 2015-11-03 21:30 +0100
    [RFC PATCH 28/28] lkl tools: add support for Windows host Octavian Purdila <octavian.purdila@intel.com> - 2015-11-03 21:30 +0100
    [RFC PATCH 09/28] lkl: timers, time and delay support Octavian Purdila <octavian.purdila@intel.com> - 2015-11-03 21:30 +0100
    [RFC PATCH 16/28] lkl tools: host lib: add lkl_strerror and lkl_printf Octavian Purdila <octavian.purdila@intel.com> - 2015-11-03 21:30 +0100
    [RFC PATCH 01/28] asm-generic: atomic64: allow using generic atomic64 on 64bit platforms Octavian Purdila <octavian.purdila@intel.com> - 2015-11-03 21:40 +0100
    [RFC PATCH 04/28] lkl: host interface Octavian Purdila <octavian.purdila@intel.com> - 2015-11-03 21:40 +0100
      Re: [RFC PATCH 04/28] lkl: host interface Hajime Tazaki <thehajime@gmail.com> - 2015-11-04 00:40 +0100
    [RFC PATCH 05/28] lkl: memory handling Octavian Purdila <octavian.purdila@intel.com> - 2015-11-03 21:40 +0100
    [RFC PATCH 07/28] lkl: interrupt support Octavian Purdila <octavian.purdila@intel.com> - 2015-11-03 21:40 +0100
    [RFC PATCH 06/28] lkl: kernel threads support Octavian Purdila <octavian.purdila@intel.com> - 2015-11-03 21:40 +0100
    [RFC PATCH 03/28] lkl: architecture skeleton for Linux kernel library Octavian Purdila <octavian.purdila@intel.com> - 2015-11-03 21:40 +0100
    Re: [RFC PATCH 00/28] Linux Kernel Library Richard Weinberger <richard.weinberger@gmail.com> - 2015-11-03 22:50 +0100
      Re: [RFC PATCH 00/28] Linux Kernel Library "Richard W.M. Jones" <rjones@redhat.com> - 2015-11-03 23:50 +0100
        Re: [RFC PATCH 00/28] Linux Kernel Library Octavian Purdila <octavian.purdila@intel.com> - 2015-11-04 00:30 +0100
          Re: [RFC PATCH 00/28] Linux Kernel Library Austin S Hemmelgarn <ahferroin7@gmail.com> - 2015-11-04 14:30 +0100
          Re: [RFC PATCH 00/28] Linux Kernel Library "Richard W.M. Jones" <rjones@redhat.com> - 2015-11-04 15:00 +0100
            Re: [RFC PATCH 00/28] Linux Kernel Library Octavian Purdila <octavian.purdila@intel.com> - 2015-11-04 15:30 +0100
              Re: [RFC PATCH 00/28] Linux Kernel Library Richard Weinberger <richard@nod.at> - 2015-11-07 01:40 +0100
                Re: [RFC PATCH 00/28] Linux Kernel Library "Richard W.M. Jones" <rjones@redhat.com> - 2015-11-07 08:20 +0100
                Re: [RFC PATCH 00/28] Linux Kernel Library "Richard W.M. Jones" <rjones@redhat.com> - 2015-11-07 11:50 +0100
                  Re: [RFC PATCH 00/28] Linux Kernel Library Octavian Purdila <octavian.purdila@intel.com> - 2015-11-09 17:40 +0100
                Re: [RFC PATCH 00/28] Linux Kernel Library Octavian Purdila <octavian.purdila@intel.com> - 2015-11-08 05:20 +0100
                Re: [RFC PATCH 00/28] Linux Kernel Library Octavian Purdila <octavian.purdila@intel.com> - 2015-11-08 05:40 +0100
        Re: [RFC PATCH 00/28] Linux Kernel Library Hajime Tazaki <thehajime@gmail.com> - 2015-11-04 00:30 +0100
      Re: [RFC PATCH 00/28] Linux Kernel Library Octavian Purdila <octavian.purdila@intel.com> - 2015-11-04 00:10 +0100
        Re: [RFC PATCH 00/28] Linux Kernel Library Octavian Purdila <octavian.purdila@intel.com> - 2015-11-09 16:20 +0100
    Re: [RFC PATCH 00/28] Linux Kernel Library Hajime Tazaki <thehajime@gmail.com> - 2015-11-08 14:50 +0100

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

#1261876 — [RFC PATCH 04/28] lkl: host interface

FromOctavian Purdila <octavian.purdila@intel.com>
Date2015-11-03 21:40 +0100
Subject[RFC PATCH 04/28] lkl: host interface
Message-ID<qqQx4-7Ef-9@gated-at.bofh.it>
In reply to#1261858
This patch introduces the host operations that define the interface
between the LKL and the host. These operations must be provided either
by a host library or by the application itself.

Signed-off-by: Octavian Purdila <octavian.purdila@intel.com>
---
 arch/lkl/include/asm/host_ops.h      |  9 ++++
 arch/lkl/include/uapi/asm/host_ops.h | 81 ++++++++++++++++++++++++++++++++++++
 2 files changed, 90 insertions(+)
 create mode 100644 arch/lkl/include/asm/host_ops.h
 create mode 100644 arch/lkl/include/uapi/asm/host_ops.h

diff --git a/arch/lkl/include/asm/host_ops.h b/arch/lkl/include/asm/host_ops.h
new file mode 100644
index 0000000..7fb0381
--- /dev/null
+++ b/arch/lkl/include/asm/host_ops.h
@@ -0,0 +1,9 @@
+#ifndef _ASM_LKL_HOST_OPS_H
+#define _ASM_LKL_HOST_OPS_H
+
+#include "irq.h"
+#include <uapi/asm/host_ops.h>
+
+extern struct lkl_host_operations *lkl_ops;
+
+#endif
diff --git a/arch/lkl/include/uapi/asm/host_ops.h b/arch/lkl/include/uapi/asm/host_ops.h
new file mode 100644
index 0000000..e126154
--- /dev/null
+++ b/arch/lkl/include/uapi/asm/host_ops.h
@@ -0,0 +1,81 @@
+#ifndef _ASM_UAPI_LKL_HOST_OPS_H
+#define _ASM_UAPI_LKL_HOST_OPS_H
+
+/**
+ * lkl_host_operations - host operations used by the Linux kernel
+ *
+ * These operations must be provided by a host library or by the application
+ * itself.
+ *
+ * @virtio_devices - string containg the list of virtio devices in virtio mmio
+ * command line format. This string is appended to the kernel command line and
+ * is provided here for convenience to be implemented by the host library.
+ *
+ * @print - optional operation that receives console messages
+ *
+ * @panic - called during a kernel panic
+ *
+ * @sem_alloc - allocate a host semaphore an initialize it to count
+ * @sem_free - free a host semaphore
+ * @sem_up - perform an up operation on the semaphore
+ * @sem_down - perform a down operation on the semaphore
+ *
+ * @thread_create - create a new thread and run f(arg) in its context; returns a
+ * thread handle or NULL if the thread could not be created
+ * @thread_exit - terminates the current thread
+ *
+ * @mem_alloc - allocate memory
+ * @mem_free - free memory
+ *
+ * @timer_create - allocate a host timer that runs fn(arg) when the timer
+ * fires.
+ * @timer_free - disarms and free the timer
+ * @timer_set_oneshot - arm the timer to fire once, after delta ns.
+ * @timer_set_periodic - arm the timer to fire periodically, with a period of
+ * delta ns.
+ *
+ */
+struct lkl_host_operations {
+	const char *virtio_devices;
+
+	void (*print)(const char *str, int len);
+	void (*panic)(void);
+
+	void* (*sem_alloc)(int count);
+	void (*sem_free)(void *sem);
+	void (*sem_up)(void *sem);
+	void (*sem_down)(void *sem);
+
+	int (*thread_create)(void (*f)(void *), void *arg);
+	void (*thread_exit)(void);
+
+	void* (*mem_alloc)(unsigned long);
+	void (*mem_free)(void *);
+
+	unsigned long long (*time)(void);
+
+	void* (*timer_alloc)(void (*fn)(void *), void *arg);
+	int (*timer_set_oneshot)(void *timer, unsigned long delta);
+	void (*timer_free)(void *timer);
+
+	void* (*ioremap)(long addr, int size);
+	int (*iomem_access)(const volatile void *addr, void *val, int size,
+			    int write);
+
+};
+
+/**
+ * lkl_start_kernel - registers the host operations and starts the kernel
+ *
+ * The function returns only after the kernel is shutdown with lkl_sys_halt.
+ *
+ * @lkl_ops - pointer to host operations
+ * @mem_size - how much memory to allocate to the Linux kernel
+ * @cmd_line - format for command line string that is going to be used to
+ * generate the Linux kernel command line
+ */
+int lkl_start_kernel(struct lkl_host_operations *lkl_ops,
+		     unsigned long mem_size,
+		     const char *cmd_line, ...);
+
+#endif
-- 
2.1.0

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1261966 — Re: [RFC PATCH 04/28] lkl: host interface

FromHajime Tazaki <thehajime@gmail.com>
Date2015-11-04 00:40 +0100
SubjectRe: [RFC PATCH 04/28] lkl: host interface
Message-ID<qqTlg-Z8-9@gated-at.bofh.it>
In reply to#1261876
At Tue,  3 Nov 2015 22:20:35 +0200,
Octavian Purdila wrote:
> 
> This patch introduces the host operations that define the interface
> between the LKL and the host. These operations must be provided either
> by a host library or by the application itself.
(snip)
> +struct lkl_host_operations {
> +	const char *virtio_devices;
> +
> +	void (*print)(const char *str, int len);
> +	void (*panic)(void);
> +
> +	void* (*sem_alloc)(int count);
> +	void (*sem_free)(void *sem);
> +	void (*sem_up)(void *sem);
> +	void (*sem_down)(void *sem);
> +
> +	int (*thread_create)(void (*f)(void *), void *arg);
> +	void (*thread_exit)(void);
> +
> +	void* (*mem_alloc)(unsigned long);
> +	void (*mem_free)(void *);
> +
> +	unsigned long long (*time)(void);
> +
> +	void* (*timer_alloc)(void (*fn)(void *), void *arg);
> +	int (*timer_set_oneshot)(void *timer, unsigned long delta);
> +	void (*timer_free)(void *timer);
> +
> +	void* (*ioremap)(long addr, int size);
> +	int (*iomem_access)(const volatile void *addr, void *val, int size,
> +			    int write);
> +
> +};

this is related to the thing that I'm improving libos right now.
my current conclusion is using rump hypercall interfaces,
which I'm currently working on. 

we (libos and lkl) may have matured interface as well as
reduce/share the effort to have more underlying (host)
calls.

-- Hajime

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1261877 — [RFC PATCH 05/28] lkl: memory handling

FromOctavian Purdila <octavian.purdila@intel.com>
Date2015-11-03 21:40 +0100
Subject[RFC PATCH 05/28] lkl: memory handling
Message-ID<qqQx4-7Ef-11@gated-at.bofh.it>
In reply to#1261858
LKL is a non MMU architecture and hence there is not much work left to
do other than initializing the boot allocator and providing the page
and page table definitions.

The backstore memory is allocated via a host operation and the memory
size to be used is specified when the kernel is started, in the
lkl_start_kernel call.

Signed-off-by: Octavian Purdila <octavian.purdila@intel.com>
---
 arch/lkl/include/asm/page.h    | 13 ++++++++
 arch/lkl/include/asm/pgtable.h | 60 +++++++++++++++++++++++++++++++++++++
 arch/lkl/kernel/mem.c          | 67 ++++++++++++++++++++++++++++++++++++++++++
 3 files changed, 140 insertions(+)
 create mode 100644 arch/lkl/include/asm/page.h
 create mode 100644 arch/lkl/include/asm/pgtable.h
 create mode 100644 arch/lkl/kernel/mem.c

diff --git a/arch/lkl/include/asm/page.h b/arch/lkl/include/asm/page.h
new file mode 100644
index 0000000..455bf62
--- /dev/null
+++ b/arch/lkl/include/asm/page.h
@@ -0,0 +1,13 @@
+#ifndef _ASM_LKL_PAGE_H
+#define _ASM_LKL_PAGE_H
+
+#define CONFIG_KERNEL_RAM_BASE_ADDRESS memory_start
+
+#ifndef __ASSEMBLY__
+void free_mem(void);
+void bootmem_init(int mem_size);
+#endif
+
+#include <asm-generic/page.h>
+
+#endif /* _ASM_LKL_PAGE_H */
diff --git a/arch/lkl/include/asm/pgtable.h b/arch/lkl/include/asm/pgtable.h
new file mode 100644
index 0000000..726675a
--- /dev/null
+++ b/arch/lkl/include/asm/pgtable.h
@@ -0,0 +1,60 @@
+#ifndef _LKL_PGTABLE_H
+#define _LKL_PGTABLE_H
+
+#include <asm-generic/4level-fixup.h>
+
+/*
+ * (C) Copyright 2000-2002, Greg Ungerer <gerg@snapgear.com>
+ */
+
+#include <linux/slab.h>
+#include <asm/processor.h>
+#include <asm/io.h>
+
+#define pgd_present(pgd)	(1)
+#define pgd_none(pgd)		(0)
+#define pgd_bad(pgd)		(0)
+#define pgd_clear(pgdp)
+#define kern_addr_valid(addr)	(1)
+#define	pmd_offset(a, b)	((void *)0)
+
+#define PAGE_NONE		__pgprot(0)
+#define PAGE_SHARED		__pgprot(0)
+#define PAGE_COPY		__pgprot(0)
+#define PAGE_READONLY		__pgprot(0)
+#define PAGE_KERNEL		__pgprot(0)
+
+void paging_init(void);
+#define swapper_pg_dir		((pgd_t *)0)
+
+#define __swp_type(x)		(0)
+#define __swp_offset(x)		(0)
+#define __swp_entry(typ, off)	((swp_entry_t) { ((typ) | ((off) << 7)) })
+#define __pte_to_swp_entry(pte)	((swp_entry_t) { pte_val(pte) })
+#define __swp_entry_to_pte(x)	((pte_t) { (x).val })
+
+/*
+ * ZERO_PAGE is a global shared page that is always zero: used
+ * for zero-mapped memory areas etc..
+ */
+#define ZERO_PAGE(vaddr)	(virt_to_page(0))
+
+/*
+ * No page table caches to initialise.
+ */
+#define pgtable_cache_init()	do { } while (0)
+
+/*
+ * All 32bit addresses are effectively valid for vmalloc...
+ * Sort of meaningless for non-VM targets.
+ */
+#define	VMALLOC_START		0
+#define	VMALLOC_END		0xffffffff
+#define	KMAP_START		0
+#define	KMAP_END		0xffffffff
+
+#include <asm-generic/pgtable.h>
+
+#define check_pgt_cache()	do { } while (0)
+
+#endif
diff --git a/arch/lkl/kernel/mem.c b/arch/lkl/kernel/mem.c
new file mode 100644
index 0000000..225c2cc
--- /dev/null
+++ b/arch/lkl/kernel/mem.c
@@ -0,0 +1,67 @@
+#include <linux/bootmem.h>
+#include <linux/mm.h>
+#include <linux/swap.h>
+
+unsigned long memory_start, memory_end;
+static unsigned long _memory_start, mem_size;
+
+void __init bootmem_init(int mem_size)
+{
+	int bootmap_size;
+
+	_memory_start = (unsigned long)lkl_ops->mem_alloc(mem_size);
+	memory_start = _memory_start;
+	BUG_ON(!memory_start);
+	memory_end = memory_start + mem_size;
+
+	if (PAGE_ALIGN(memory_start) != memory_start) {
+		mem_size -= PAGE_ALIGN(memory_start) - memory_start;
+		memory_start = PAGE_ALIGN(memory_start);
+		mem_size = (mem_size / PAGE_SIZE) * PAGE_SIZE;
+	}
+
+	/*
+	 * Give all the memory to the bootmap allocator, tell it to put the
+	 * boot mem_map at the start of memory.
+	 */
+	max_low_pfn = virt_to_pfn(memory_end);
+	min_low_pfn = virt_to_pfn(memory_start);
+	bootmap_size = init_bootmem_node(NODE_DATA(0), min_low_pfn, min_low_pfn,
+					 max_low_pfn);
+
+	/*
+	 * Free the usable memory, we have to make sure we do not free
+	 * the bootmem bitmap so we then reserve it after freeing it :-)
+	 */
+	free_bootmem(memory_start, mem_size);
+	reserve_bootmem(memory_start, bootmap_size, BOOTMEM_DEFAULT);
+
+	{
+		unsigned long zones_size[MAX_NR_ZONES] = {0, };
+
+		zones_size[ZONE_NORMAL] = (mem_size) >> PAGE_SHIFT;
+		free_area_init(zones_size);
+	}
+}
+
+void __init mem_init(void)
+{
+	max_mapnr = (((unsigned long)high_memory) - PAGE_OFFSET) >> PAGE_SHIFT;
+	/* this will put all memory onto the freelists */
+	totalram_pages = free_all_bootmem();
+	pr_info("Memory available: %luk/%luk RAM\n",
+		(nr_free_pages() << PAGE_SHIFT) >> 10, mem_size >> 10);
+}
+
+/*
+ * In our case __init memory is not part of the page allocator so there is
+ * nothing to free.
+ */
+void free_initmem(void)
+{
+}
+
+void free_mem(void)
+{
+	lkl_ops->mem_free((void *)_memory_start);
+}
-- 
2.1.0

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1261878 — [RFC PATCH 07/28] lkl: interrupt support

FromOctavian Purdila <octavian.purdila@intel.com>
Date2015-11-03 21:40 +0100
Subject[RFC PATCH 07/28] lkl: interrupt support
Message-ID<qqQx4-7Ef-13@gated-at.bofh.it>
In reply to#1261858
Add APIs that allows the host to reserve and free and interrupt number
and also to trigger an interrupt.

The trigger operation will simply store the interrupt data in
queue. The interrupt handler is run later, at the first opportunity it
has to avoid races with any kernel threads.

Currently, interrupts are run on the first interrupt enable operation
if interrupts are disabled and if we are not already in interrupt
context.

When triggering an interrupt the host can also send a void pointer
that is going to be available to the handler routine via
get_irq_regs()->irq_data. This allows to easly create host <-> kernel
synchronous communication channels and is currently used by the system
call interface.

Signed-off-by: Octavian Purdila <octavian.purdila@intel.com>
---
 arch/lkl/include/asm/irq.h             |  10 +++
 arch/lkl/include/uapi/asm/irq.h        |  37 ++++++++++
 arch/lkl/include/uapi/asm/sigcontext.h |   1 +
 arch/lkl/kernel/irq.c                  | 131 +++++++++++++++++++++++++++++++++
 4 files changed, 179 insertions(+)
 create mode 100644 arch/lkl/include/asm/irq.h
 create mode 100644 arch/lkl/include/uapi/asm/irq.h
 create mode 100644 arch/lkl/kernel/irq.c

diff --git a/arch/lkl/include/asm/irq.h b/arch/lkl/include/asm/irq.h
new file mode 100644
index 0000000..f4ceb5a
--- /dev/null
+++ b/arch/lkl/include/asm/irq.h
@@ -0,0 +1,10 @@
+#ifndef _ASM_LKL_IRQ_H
+#define _ASM_LKL_IRQ_H
+
+#define NR_IRQS		32
+
+void free_IRQ(void);
+
+#include <uapi/asm/irq.h>
+
+#endif
diff --git a/arch/lkl/include/uapi/asm/irq.h b/arch/lkl/include/uapi/asm/irq.h
new file mode 100644
index 0000000..a33f5c5
--- /dev/null
+++ b/arch/lkl/include/uapi/asm/irq.h
@@ -0,0 +1,37 @@
+#ifndef _ASM_UAPI_LKL_IRQ_H
+#define _ASM_UAPI_LKL_IRQ_H
+
+/**
+ * lkl_trigger_irq - generate an interrupt
+ *
+ * This function is used by the device host side to signal its Linux counterpart
+ * that some event happened.
+ *
+ * @irq - the irq number to signal
+ * @data - data to be passed to the irq handler; available via
+ * get_irq_regs()->irq_data
+ */
+int lkl_trigger_irq(int irq, void *data);
+
+/**
+ * lkl_get_free_irq - find and reserve a free IRQ number
+ *
+ * This function is called by the host device code to find an unused IRQ number
+ * and reserved it for its own use.
+ *
+ * @user - a string to identify the user
+ * @returns - and irq number that can be used by request_irq or an negative
+ * value in case of an error
+ */
+int lkl_get_free_irq(const char *user);
+
+/**
+ * lkl_put_irq - release an IRQ number previously obtained with lkl_get_free_irq
+ *
+ * @irq - irq number to release
+ * @user - string identifying the user; should be the same as the one passed to
+ * lkl_get_free_irq when the irq number was obtained
+ */
+void lkl_put_irq(int irq, const char *name);
+
+#endif
diff --git a/arch/lkl/include/uapi/asm/sigcontext.h b/arch/lkl/include/uapi/asm/sigcontext.h
index 99b2d53..77aba40 100644
--- a/arch/lkl/include/uapi/asm/sigcontext.h
+++ b/arch/lkl/include/uapi/asm/sigcontext.h
@@ -4,6 +4,7 @@
 #include <asm/ptrace.h>
 
 struct pt_regs {
+	void *irq_data;
 };
 
 struct sigcontext {
diff --git a/arch/lkl/kernel/irq.c b/arch/lkl/kernel/irq.c
new file mode 100644
index 0000000..9ff0e12
--- /dev/null
+++ b/arch/lkl/kernel/irq.c
@@ -0,0 +1,131 @@
+#include <linux/kernel.h>
+#include <linux/init.h>
+#include <linux/irq.h>
+#include <linux/hardirq.h>
+#include <asm/irq_regs.h>
+#include <linux/sched.h>
+#include <linux/seq_file.h>
+#include <linux/tick.h>
+#include <asm/irqflags.h>
+#include <asm/host_ops.h>
+
+static bool irqs_enabled;
+
+#define MAX_IRQS	16
+static struct irq_info {
+	struct pt_regs regs[MAX_IRQS];
+	const char *user;
+	int count;
+} irqs[NR_IRQS];
+static void *irqs_lock;
+
+static void do_IRQ(int irq, struct pt_regs *regs)
+{
+	struct pt_regs *old_regs = set_irq_regs(regs);
+
+	irq_enter();
+	generic_handle_irq(irq);
+	irq_exit();
+
+	set_irq_regs(old_regs);
+}
+
+int lkl_trigger_irq(int irq, void *data)
+{
+	struct pt_regs regs = {
+		.irq_data = data,
+	};
+	int ret = 0;
+
+	if (irq >= NR_IRQS)
+		return -EINVAL;
+
+	lkl_ops->sem_down(irqs_lock);
+	if (irqs[irq].count < MAX_IRQS) {
+		irqs[irq].regs[irqs[irq].count] = regs;
+		irqs[irq].count++;
+	} else {
+		ret = -EOVERFLOW;
+	}
+	lkl_ops->sem_up(irqs_lock);
+
+	wakeup_cpu();
+
+	return ret;
+}
+
+static void run_irqs(void)
+{
+	int i, j;
+
+	lkl_ops->sem_down(irqs_lock);
+	for (i = 0; i < NR_IRQS; i++) {
+		for (j = 0; j < irqs[i].count; j++)
+			do_IRQ(i, &irqs[i].regs[j]);
+		irqs[i].count = 0;
+	}
+	lkl_ops->sem_up(irqs_lock);
+}
+
+int show_interrupts(struct seq_file *p, void *v)
+{
+	return 0;
+}
+
+int lkl_get_free_irq(const char *user)
+{
+	int i;
+	int ret = -EBUSY;
+
+	/* 0 is not a valid IRQ */
+	for (i = 1; i < NR_IRQS; i++) {
+		if (!irqs[i].user) {
+			irqs[i].user = user;
+			ret = i;
+			break;
+		}
+	}
+
+	return ret;
+}
+
+void lkl_put_irq(int i, const char *user)
+{
+	if (!irqs[i].user || strcmp(irqs[i].user, user) != 0) {
+		WARN("%s tried to release %s's irq %d", user, irqs[i].user, i);
+		return;
+	}
+
+	irqs[i].user = NULL;
+}
+
+unsigned long arch_local_save_flags(void)
+{
+	return irqs_enabled;
+}
+
+void arch_local_irq_restore(unsigned long flags)
+{
+	if (flags == ARCH_IRQ_ENABLED && irqs_enabled == ARCH_IRQ_DISABLED &&
+	    !in_interrupt())
+		run_irqs();
+	irqs_enabled = flags;
+}
+
+void free_IRQ(void)
+{
+	lkl_ops->sem_free(irqs_lock);
+}
+
+void init_IRQ(void)
+{
+	int i;
+
+	irqs_lock = lkl_ops->sem_alloc(1);
+	BUG_ON(!irqs_lock);
+
+	for (i = 0; i < NR_IRQS; i++)
+		irq_set_chip_and_handler(i, &dummy_irq_chip, handle_simple_irq);
+
+	pr_info("lkl: irqs initialized\n");
+}
-- 
2.1.0

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1261880 — [RFC PATCH 06/28] lkl: kernel threads support

FromOctavian Purdila <octavian.purdila@intel.com>
Date2015-11-03 21:40 +0100
Subject[RFC PATCH 06/28] lkl: kernel threads support
Message-ID<qqQx4-7Ef-19@gated-at.bofh.it>
In reply to#1261858
LKL does not support user processes but it must support kernel threads
as part as the normal kernel work-flow. It uses host operations to
create and terminate host threads that are going to run the kernel
threads. It also uses semaphores to synchronize those threads and to
allow the Linux kernel scheduler to control how the kernel threads
run.

Each kernel thread runs in a host threads and has a host semaphore
associated with it - the thread's scheduling semaphore. The semaphore
counter is initialized to 0. The first thing a kernel thread does
after getting spawned, before running any kernel code, is to perform a
down operation to block the thread.

The kernel controls host threads scheduling by performing up and down
operations on the scheduling semaphore. In __switch_context an up
operation on the next thread is performed to wake up a blocked thread,
and a down operation is performed on the prev thread to block it.

A thread is terminated by marking it in free_thread_info and
performing an up operation on the scheduling semaphore at which point
the marked thread will terminate itself.

Signed-off-by: Octavian Purdila <octavian.purdila@intel.com>
---
 arch/lkl/include/asm/thread_info.h |  82 +++++++++++++
 arch/lkl/kernel/threads.c          | 235 +++++++++++++++++++++++++++++++++++++
 2 files changed, 317 insertions(+)
 create mode 100644 arch/lkl/include/asm/thread_info.h
 create mode 100644 arch/lkl/kernel/threads.c

diff --git a/arch/lkl/include/asm/thread_info.h b/arch/lkl/include/asm/thread_info.h
new file mode 100644
index 0000000..7636227
--- /dev/null
+++ b/arch/lkl/include/asm/thread_info.h
@@ -0,0 +1,82 @@
+#ifndef _ASM_LKL_THREAD_INFO_H
+#define _ASM_LKL_THREAD_INFO_H
+
+#define THREAD_SIZE	       (4096)
+
+#ifndef __ASSEMBLY__
+#include <asm/types.h>
+#include <asm/processor.h>
+
+typedef struct {
+	unsigned long seg;
+} mm_segment_t;
+
+struct thread_exit_info {
+	bool dead;
+	void *sched_sem;
+};
+
+struct thread_info {
+	struct task_struct *task;
+	unsigned long flags;
+	int preempt_count;
+	mm_segment_t addr_limit;
+	void *sched_sem;
+	struct thread_exit_info *exit_info;
+	struct task_struct *prev_sched;
+	unsigned long stackend;
+};
+
+#define INIT_THREAD_INFO(tsk)				\
+{							\
+	.task		= &tsk,				\
+	.preempt_count	= INIT_PREEMPT_COUNT,		\
+	.flags		= 0,				\
+	.addr_limit	= KERNEL_DS,			\
+}
+
+#define init_thread_info	(init_thread_union.thread_info)
+#define init_stack		(init_thread_union.stack)
+
+/* how to get the thread information struct from C */
+extern struct thread_info *_current_thread_info;
+static inline struct thread_info *current_thread_info(void)
+{
+	return _current_thread_info;
+}
+
+/* thread information allocation */
+struct thread_info *alloc_thread_info_node(struct task_struct *, int node);
+void free_thread_info(struct thread_info *);
+
+int threads_init(void);
+void threads_cleanup(void);
+
+#define TIF_SYSCALL_TRACE		0
+#define TIF_NOTIFY_RESUME		1
+#define TIF_SIGPENDING			2
+#define TIF_NEED_RESCHED		3
+#define TIF_RESTORE_SIGMASK		4
+#define TIF_MEMDIE			5
+#define TIF_NOHZ			6
+
+#define __HAVE_THREAD_FUNCTIONS
+
+#define task_thread_info(task)	((struct thread_info *)(task)->stack)
+#define task_stack_page(task)	((task)->stack)
+
+/*
+ * Nothing to do here. The only new tasks created are kernel threads that have a
+ * predefined starting point thus no stack copy is required as for regular
+ * forked tasks.
+ */
+static inline void setup_thread_stack(struct task_struct *p,
+				      struct task_struct *org)
+{
+}
+
+#define end_of_stack(p) (&task_thread_info(p)->stackend)
+
+#endif /* __ASSEMBLY__ */
+
+#endif
diff --git a/arch/lkl/kernel/threads.c b/arch/lkl/kernel/threads.c
new file mode 100644
index 0000000..aa13e57
--- /dev/null
+++ b/arch/lkl/kernel/threads.c
@@ -0,0 +1,235 @@
+#include <linux/module.h>
+#include <linux/slab.h>
+#include <linux/sched.h>
+#include <asm/host_ops.h>
+
+static int threads_counter;
+static void *threads_counter_lock;
+
+static inline void threads_counter_inc(void)
+{
+	lkl_ops->sem_down(threads_counter_lock);
+	threads_counter++;
+	lkl_ops->sem_up(threads_counter_lock);
+}
+
+static inline void threads_counter_dec(void)
+{
+	lkl_ops->sem_down(threads_counter_lock);
+	threads_counter--;
+	lkl_ops->sem_up(threads_counter_lock);
+}
+
+static inline int threads_counter_get(void)
+{
+	int counter;
+
+	lkl_ops->sem_down(threads_counter_lock);
+	counter = threads_counter;
+	lkl_ops->sem_up(threads_counter_lock);
+
+	return counter;
+}
+
+struct thread_info *alloc_thread_info_node(struct task_struct *task, int node)
+{
+	struct thread_info *ti;
+
+	ti = kmalloc(sizeof(*ti), GFP_KERNEL);
+	if (!ti)
+		return NULL;
+
+	ti->exit_info = NULL;
+	ti->prev_sched = NULL;
+	ti->sched_sem = lkl_ops->sem_alloc(0);
+	ti->task = task;
+	if (!ti->sched_sem) {
+		kfree(ti);
+		return NULL;
+	}
+
+	return ti;
+}
+
+static void kill_thread(struct thread_exit_info *ei)
+{
+	if (WARN_ON(!ei))
+		return;
+
+	ei->dead = true;
+	lkl_ops->sem_up(ei->sched_sem);
+}
+
+void free_thread_info(struct thread_info *ti)
+{
+	struct thread_exit_info *ei = ti->exit_info;
+
+	kfree(ti);
+	kill_thread(ei);
+}
+
+struct thread_info *_current_thread_info = &init_thread_union.thread_info;
+
+struct task_struct *__switch_to(struct task_struct *prev,
+				struct task_struct *next)
+{
+	struct thread_info *_prev = task_thread_info(prev);
+	struct thread_info *_next = task_thread_info(next);
+	/*
+	 * schedule() expects the return of this function to be the task that we
+	 * switched away from. Returning prev is not going to work because we
+	 * are actually going to return the previous taks that was scheduled
+	 * before the task we are going to wake up, and not the current task,
+	 * e.g.:
+	 *
+	 * swapper -> init: saved prev on swapper stack is swapper
+	 * init -> ksoftirqd0: saved prev on init stack is init
+	 * ksoftirqd0 -> swapper: returned prev is swapper
+	 */
+	static struct task_struct *abs_prev = &init_task;
+	/*
+	 * We need to free the thread_info structure in free_thread_info to
+	 * avoid races between the dying thread and other threads. We also need
+	 * to cleanup sched_sem and signal to the prev thread that it needs to
+	 * exit, and we use this stack varible to pass this info.
+	 */
+	struct thread_exit_info ei = {
+		.dead = false,
+		.sched_sem = _prev->sched_sem,
+	};
+
+	_current_thread_info = task_thread_info(next);
+	_next->prev_sched = prev;
+	abs_prev = prev;
+	_prev->exit_info = &ei;
+
+	lkl_ops->sem_up(_next->sched_sem);
+	/* _next may be already gone so use ei instead */
+	lkl_ops->sem_down(ei.sched_sem);
+
+	if (ei.dead) {
+		lkl_ops->sem_free(ei.sched_sem);
+		threads_counter_dec();
+		lkl_ops->thread_exit();
+	}
+
+	_prev->exit_info = NULL;
+
+	return abs_prev;
+}
+
+struct thread_bootstrap_arg {
+	struct thread_info *ti;
+	int (*f)(void *);
+	void *arg;
+};
+
+static void thread_bootstrap(void *_tba)
+{
+	struct thread_bootstrap_arg *tba = (struct thread_bootstrap_arg *)_tba;
+	struct thread_info *ti = tba->ti;
+	int (*f)(void *) = tba->f;
+	void *arg = tba->arg;
+
+	lkl_ops->sem_down(ti->sched_sem);
+	kfree(tba);
+	if (ti->prev_sched)
+		schedule_tail(ti->prev_sched);
+
+	f(arg);
+	do_exit(0);
+}
+
+int copy_thread(unsigned long clone_flags, unsigned long esp,
+		unsigned long unused, struct task_struct *p)
+{
+	struct thread_info *ti = task_thread_info(p);
+	struct thread_bootstrap_arg *tba;
+	int ret;
+
+	tba = kmalloc(sizeof(*tba), GFP_KERNEL);
+	if (!tba)
+		return -ENOMEM;
+
+	tba->f = (int (*)(void *))esp;
+	tba->arg = (void *)unused;
+	tba->ti = ti;
+
+	ret = lkl_ops->thread_create(thread_bootstrap, tba);
+	if (ret) {
+		kfree(tba);
+		return -ENOMEM;
+	}
+
+	threads_counter_inc();
+
+	return 0;
+}
+
+void show_stack(struct task_struct *task, unsigned long *esp)
+{
+}
+
+static inline void pr_early(const char *str)
+{
+	if (lkl_ops->print)
+		lkl_ops->print(str, strlen(str));
+}
+
+/**
+ * This is called before the kernel initializes, so no kernel calls (including
+ * printk) can't be made yet.
+ */
+int threads_init(void)
+{
+	struct thread_info *ti = &init_thread_union.thread_info;
+	int ret = 0;
+
+	ti->exit_info = NULL;
+	ti->prev_sched = NULL;
+
+	ti->sched_sem = lkl_ops->sem_alloc(0);
+	if (!ti->sched_sem) {
+		pr_early("lkl: failed to allocate init schedule semaphore\n");
+		ret = -ENOMEM;
+		goto out;
+	}
+
+	threads_counter_lock = lkl_ops->sem_alloc(1);
+	if (!threads_counter_lock) {
+		pr_early("lkl: failed to alllocate threads counter lock\n");
+		ret = -ENOMEM;
+		goto out_free_init_sched_sem;
+	}
+
+	return 0;
+
+out_free_init_sched_sem:
+	lkl_ops->sem_free(ti->sched_sem);
+
+out:
+	return ret;
+}
+
+void threads_cleanup(void)
+{
+	struct task_struct *p;
+
+	for_each_process(p) {
+		struct thread_info *ti = task_thread_info(p);
+
+		if (p->pid != 1)
+			WARN(!(p->flags & PF_KTHREAD),
+			     "non kernel thread task %p\n", p->comm);
+		WARN(p->state == TASK_RUNNING,
+		     "thread %s still running while halting\n", p->comm);
+
+		kill_thread(ti->exit_info);
+	}
+
+	while (threads_counter_get())
+		;
+
+	lkl_ops->sem_free(init_thread_union.thread_info.sched_sem);
+	lkl_ops->sem_free(threads_counter_lock);
+}
-- 
2.1.0

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1261883 — [RFC PATCH 03/28] lkl: architecture skeleton for Linux kernel library

FromOctavian Purdila <octavian.purdila@intel.com>
Date2015-11-03 21:40 +0100
Subject[RFC PATCH 03/28] lkl: architecture skeleton for Linux kernel library
Message-ID<qqQx4-7Ef-25@gated-at.bofh.it>
In reply to#1261858
Adds the LKL Kconfig, vmlinux linker script, basic architecture
headers and miscellaneous basic functions or stubs such as
dump_stack(), show_regs() and cpuinfo proc ops.

The headers we introduce in this patch are simple wrappers to the
asm-generic headers or stubs for things we don't support, such as
ptrace, DMA, signals, ELF handling and low level processor operations.

The kernel configuration is automatically updated to reflect the
endianness of the host, 64bit support or the output format for
vmlinux's linker script. We do this by looking at the ld's default
output format.

Signed-off-by: Octavian Purdila <octavian.purdila@intel.com>
---
 MAINTAINERS                             |  5 ++
 arch/lkl/.gitignore                     |  1 +
 arch/lkl/Kconfig                        | 82 +++++++++++++++++++++++++++++++++
 arch/lkl/auto.conf                      |  1 +
 arch/lkl/defconfig                      | 35 ++++++++++++++
 arch/lkl/include/asm/Kbuild             | 77 +++++++++++++++++++++++++++++++
 arch/lkl/include/asm/bitsperlong.h      | 11 +++++
 arch/lkl/include/asm/byteorder.h        | 10 ++++
 arch/lkl/include/asm/dma-mapping.h      |  6 +++
 arch/lkl/include/asm/elf.h              | 13 ++++++
 arch/lkl/include/asm/mutex.h            |  7 +++
 arch/lkl/include/asm/processor.h        | 53 +++++++++++++++++++++
 arch/lkl/include/asm/ptrace.h           | 23 +++++++++
 arch/lkl/include/asm/vmlinux.lds.h      | 15 ++++++
 arch/lkl/include/uapi/asm/Kbuild        | 38 +++++++++++++++
 arch/lkl/include/uapi/asm/bitsperlong.h | 12 +++++
 arch/lkl/include/uapi/asm/sigcontext.h  | 14 ++++++
 arch/lkl/kernel/asm-offsets.c           |  1 +
 arch/lkl/kernel/misc.c                  | 57 +++++++++++++++++++++++
 arch/lkl/kernel/vmlinux.lds.S           | 45 ++++++++++++++++++
 20 files changed, 506 insertions(+)
 create mode 100644 arch/lkl/.gitignore
 create mode 100644 arch/lkl/Kconfig
 create mode 100644 arch/lkl/auto.conf
 create mode 100644 arch/lkl/defconfig
 create mode 100644 arch/lkl/include/asm/Kbuild
 create mode 100644 arch/lkl/include/asm/bitsperlong.h
 create mode 100644 arch/lkl/include/asm/byteorder.h
 create mode 100644 arch/lkl/include/asm/dma-mapping.h
 create mode 100644 arch/lkl/include/asm/elf.h
 create mode 100644 arch/lkl/include/asm/mutex.h
 create mode 100644 arch/lkl/include/asm/processor.h
 create mode 100644 arch/lkl/include/asm/ptrace.h
 create mode 100644 arch/lkl/include/asm/vmlinux.lds.h
 create mode 100644 arch/lkl/include/uapi/asm/Kbuild
 create mode 100644 arch/lkl/include/uapi/asm/bitsperlong.h
 create mode 100644 arch/lkl/include/uapi/asm/sigcontext.h
 create mode 100644 arch/lkl/kernel/asm-offsets.c
 create mode 100644 arch/lkl/kernel/misc.c
 create mode 100644 arch/lkl/kernel/vmlinux.lds.S

diff --git a/MAINTAINERS b/MAINTAINERS
index 77ed3a0..e2a737f 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -6355,6 +6355,11 @@ F:	arch/powerpc/platforms/pasemi/
 F:	drivers/*/*pasemi*
 F:	drivers/*/*/*pasemi*
 
+LINUX KERNEL LIBRARY
+M:	Octavian Purdila <octavian.purdila@intel.com>
+S:	Maintained
+F:	arch/lkl/
+
 LINUX SECURITY MODULE (LSM) FRAMEWORK
 M:	Chris Wright <chrisw@sous-sol.org>
 L:	linux-security-module@vger.kernel.org
diff --git a/arch/lkl/.gitignore b/arch/lkl/.gitignore
new file mode 100644
index 0000000..c619b7d
--- /dev/null
+++ b/arch/lkl/.gitignore
@@ -0,0 +1 @@
+kernel/vmlinux.lds
diff --git a/arch/lkl/Kconfig b/arch/lkl/Kconfig
new file mode 100644
index 0000000..064960b
--- /dev/null
+++ b/arch/lkl/Kconfig
@@ -0,0 +1,82 @@
+config LKL
+       def_bool y
+       depends on !SMP && !MMU && !COREDUMP && !AUDITSYSCALL && !SECCOMP && !TRACEPOINTS && !UPROBES && !COMPAT && !USER_RETURN_NOTIFIER
+       select ARCH_THREAD_INFO_ALLOCATOR
+       select RWSEM_GENERIC_SPINLOCK
+       select GENERIC_ATOMIC64
+       select SEMAPHORE_SLEEPERS
+       select GENERIC_TIME
+       select GENERIC_FIND_NEXT_BIT
+       select GENERIC_HWEIGHT
+       select GENERIC_HARDIRQS
+       select FLATMEM
+       select FLAT_NODE_MEM_MAP
+       select GENERIC_CLOCKEVENTS
+       select GENERIC_CPU_DEVICES
+       select NO_HZ_IDLE
+       select NO_PREEMPT
+       select ARCH_WANT_FRAME_POINTERS
+       select PHYS_ADDR_T_64BIT if 64BIT
+       select 64BIT if OUTPUT_FORMAT = "elf64-x86-64"
+
+config OUTPUTFORMAT
+       string
+       option env="OUTPUT_FORMAT"
+
+config OUTPUT_FORMAT
+       string "Output format"
+       default OUTPUTFORMAT
+
+config ARCH_DMA_ADDR_T_64BIT
+       def_bool 64BIT
+
+config 64BIT
+       def_bool n
+
+config BIG_ENDIAN
+       def_bool n
+
+config NO_DMA
+       def_bool y
+
+config GENERIC_CSUM
+       def_bool y
+
+config GENERIC_HWEIGHT
+       def_bool y
+
+config NO_IOPORT_MAP
+       def_bool y
+
+config RWSEM_GENERIC_SPINLOCK
+	bool
+	default y
+
+source init/Kconfig
+
+source net/Kconfig
+
+source drivers/base/Kconfig
+
+source drivers/virtio/Kconfig
+
+source drivers/block/Kconfig
+
+source fs/Kconfig
+
+source mm/Kconfig
+
+source kernel/Kconfig.preempt
+
+source kernel/Kconfig.locks
+
+source kernel/Kconfig.hz
+
+source security/Kconfig
+
+source crypto/Kconfig
+
+source lib/Kconfig
+
+source lib/Kconfig.debug
+
diff --git a/arch/lkl/auto.conf b/arch/lkl/auto.conf
new file mode 100644
index 0000000..4bfd65a
--- /dev/null
+++ b/arch/lkl/auto.conf
@@ -0,0 +1 @@
+export OUTPUT_FORMAT=$(shell $(LD) -r -print-output-format)
diff --git a/arch/lkl/defconfig b/arch/lkl/defconfig
new file mode 100644
index 0000000..90f385d
--- /dev/null
+++ b/arch/lkl/defconfig
@@ -0,0 +1,35 @@
+# CONFIG_LOCALVERSION_AUTO is not set
+# CONFIG_USELIB is not set
+# CONFIG_SYSFS_SYSCALL is not set
+CONFIG_KALLSYMS_ALL=y
+# CONFIG_BASE_FULL is not set
+# CONFIG_FUTEX is not set
+# CONFIG_EPOLL is not set
+# CONFIG_SIGNALFD is not set
+# CONFIG_TIMERFD is not set
+# CONFIG_EVENTFD is not set
+# CONFIG_AIO is not set
+# CONFIG_ADVISE_SYSCALLS is not set
+CONFIG_EMBEDDED=y
+# CONFIG_VM_EVENT_COUNTERS is not set
+# CONFIG_COMPAT_BRK is not set
+# CONFIG_BLK_DEV_BSG is not set
+# CONFIG_UEVENT_HELPER is not set
+# CONFIG_FW_LOADER is not set
+CONFIG_VIRTIO_MMIO=y
+CONFIG_VIRTIO_MMIO_CMDLINE_DEVICES=y
+CONFIG_VIRTIO_BLK=y
+CONFIG_EXT4_FS=y
+CONFIG_EXT4_FS_POSIX_ACL=y
+CONFIG_EXT4_FS_SECURITY=y
+# CONFIG_FILE_LOCKING is not set
+# CONFIG_DNOTIFY is not set
+# CONFIG_INOTIFY_USER is not set
+# CONFIG_MISC_FILESYSTEMS is not set
+CONFIG_CRYPTO_ANSI_CPRNG=y
+CONFIG_PRINTK_TIME=y
+CONFIG_DEBUG_INFO=y
+CONFIG_DEBUG_INFO_REDUCED=y
+# CONFIG_ENABLE_WARN_DEPRECATED is not set
+# CONFIG_ENABLE_MUST_CHECK is not set
+CONFIG_SLUB_DEBUG_ON=y
diff --git a/arch/lkl/include/asm/Kbuild b/arch/lkl/include/asm/Kbuild
new file mode 100644
index 0000000..55acf3f
--- /dev/null
+++ b/arch/lkl/include/asm/Kbuild
@@ -0,0 +1,77 @@
+generic-y += atomic.h
+generic-y += barrier.h
+generic-y += bitops.h
+generic-y += bug.h
+generic-y += bugs.h
+generic-y += cache.h
+generic-y += cacheflush.h
+generic-y += checksum.h
+generic-y += cmpxchg-local.h
+generic-y += cmpxchg.h
+generic-y += cputime.h
+generic-y += current.h
+generic-y += delay.h
+generic-y += device.h
+generic-y += div64.h
+generic-y += dma.h
+generic-y += emergency-restart.h
+generic-y += errno.h
+generic-y += exec.h
+generic-y += ftrace.h
+generic-y += futex.h
+generic-y += hardirq.h
+generic-y += hw_irq.h
+generic-y += ioctl.h
+generic-y += ipcbuf.h
+generic-y += irq_regs.h
+generic-y += irqflags.h
+generic-y += irq_work.h
+generic-y += kdebug.h
+generic-y += kmap_types.h
+generic-y += linkage.h
+generic-y += local.h
+generic-y += local64.h
+generic-y += mcs_spinlock.h
+generic-y += mmu.h
+generic-y += mmu_context.h
+generic-y += module.h
+generic-y += msgbuf.h
+generic-y += page.h
+generic-y += param.h
+generic-y += parport.h
+generic-y += pci.h
+generic-y += percpu.h
+generic-y += pgalloc.h
+generic-y += poll.h
+generic-y += preempt.h
+generic-y += resource.h
+generic-y += rwsem.h
+generic-y += scatterlist.h
+generic-y += seccomp.h
+generic-y += sections.h
+generic-y += segment.h
+generic-y += sembuf.h
+generic-y += serial.h
+generic-y += shmbuf.h
+generic-y += siginfo.h
+generic-y += signal.h
+generic-y += simd.h
+generic-y += sizes.h
+generic-y += socket.h
+generic-y += sockios.h
+generic-y += stat.h
+generic-y += statfs.h
+generic-y += string.h
+generic-y += swab.h
+generic-y += switch_to.h
+generic-y += termbits.h
+generic-y += termios.h
+generic-y += time.h
+generic-y += timex.h
+generic-y += tlb.h
+generic-y += tlbflush.h
+generic-y += topology.h
+generic-y += trace_clock.h
+generic-y += uaccess.h
+generic-y += unaligned.h
+generic-y += word-at-a-time.h
diff --git a/arch/lkl/include/asm/bitsperlong.h b/arch/lkl/include/asm/bitsperlong.h
new file mode 100644
index 0000000..282b081
--- /dev/null
+++ b/arch/lkl/include/asm/bitsperlong.h
@@ -0,0 +1,11 @@
+#ifndef __LKL_BITSPERLONG_H
+#define __LKL_BITSPERLONG_H
+
+#include <uapi/asm/bitsperlong.h>
+
+#define BITS_PER_LONG __BITS_PER_LONG
+
+#define BITS_PER_LONG_LONG 64
+
+#endif
+
diff --git a/arch/lkl/include/asm/byteorder.h b/arch/lkl/include/asm/byteorder.h
new file mode 100644
index 0000000..19a5f0e
--- /dev/null
+++ b/arch/lkl/include/asm/byteorder.h
@@ -0,0 +1,10 @@
+#ifndef _ASM_LKL_BYTEORDER_H
+#define _ASM_LKL_BYTEORDER_H
+
+#if defined(CONFIG_BIG_ENDIAN)
+#include <linux/byteorder/big_endian.h>
+#else
+#include <linux/byteorder/little_endian.h>
+#endif
+
+#endif /* _ASM_LKL_BYTEORDER_H */
diff --git a/arch/lkl/include/asm/dma-mapping.h b/arch/lkl/include/asm/dma-mapping.h
new file mode 100644
index 0000000..a2e0bd9
--- /dev/null
+++ b/arch/lkl/include/asm/dma-mapping.h
@@ -0,0 +1,6 @@
+#ifndef _ASM_LKL_DMA_MAPPING_H
+#define _ASM_LKL_DMA_MAPPING_H
+
+#include <asm-generic/dma-mapping-broken.h>
+
+#endif
diff --git a/arch/lkl/include/asm/elf.h b/arch/lkl/include/asm/elf.h
new file mode 100644
index 0000000..cada3ab
--- /dev/null
+++ b/arch/lkl/include/asm/elf.h
@@ -0,0 +1,13 @@
+#ifndef _ASM_LKL_ELF_H
+#define _ASM_LKL_ELF_H
+
+#define elf_check_arch(x) 0
+
+#ifdef CONFIG_64BIT
+#define ELF_CLASS ELFCLASS64
+#else
+#define ELF_CLASS ELFCLASS32
+#endif
+
+#endif
+
diff --git a/arch/lkl/include/asm/mutex.h b/arch/lkl/include/asm/mutex.h
new file mode 100644
index 0000000..77c2c53
--- /dev/null
+++ b/arch/lkl/include/asm/mutex.h
@@ -0,0 +1,7 @@
+#ifndef _ASM_LKL_MUTEX_H
+#define _ASM_LKL_MUTEX_H
+
+#include <asm-generic/mutex-dec.h>
+
+#endif
+
diff --git a/arch/lkl/include/asm/processor.h b/arch/lkl/include/asm/processor.h
new file mode 100644
index 0000000..7f6bdb4
--- /dev/null
+++ b/arch/lkl/include/asm/processor.h
@@ -0,0 +1,53 @@
+#ifndef _ASM_LKL_PROCESSOR_H
+#define _ASM_LKL_PROCESSOR_H
+
+struct task_struct;
+
+#define cpu_relax() barrier()
+
+#define current_text_addr() ({ __label__ _l; _l: &&_l; })
+
+static inline unsigned long thread_saved_pc(struct task_struct *tsk)
+{
+	return 0;
+}
+
+static inline void release_thread(struct task_struct *dead_task)
+{
+}
+
+static inline void prepare_to_copy(struct task_struct *tsk)
+{
+}
+
+static inline unsigned long get_wchan(struct task_struct *p)
+{
+	return 0;
+}
+
+static inline void flush_thread(void)
+{
+}
+
+static inline void exit_thread(void)
+{
+}
+
+static inline void trap_init(void)
+{
+}
+
+struct thread_struct { };
+
+#define INIT_THREAD { }
+
+#define task_pt_regs(tsk) (struct pt_regs *)(NULL)
+
+/* We don't have strict user/kernel spaces */
+#define TASK_SIZE ((unsigned long)-1)
+#define TASK_UNMAPPED_BASE	0
+
+#define KSTK_EIP(tsk)	(0)
+#define KSTK_ESP(tsk)	(0)
+
+#endif
diff --git a/arch/lkl/include/asm/ptrace.h b/arch/lkl/include/asm/ptrace.h
new file mode 100644
index 0000000..f3c27e7
--- /dev/null
+++ b/arch/lkl/include/asm/ptrace.h
@@ -0,0 +1,23 @@
+#ifndef _ASM_LKL_PTRACE_H
+#define _ASM_LKL_PTRACE_H
+
+struct task_struct;
+
+#define user_mode(regs) 0
+#define kernel_mode(regs) 1
+#define profile_pc(regs) 0
+#define instruction_pointer(regs) 0
+#define user_stack_pointer(regs) 0
+
+static inline long arch_ptrace(struct task_struct *child,
+			       long request, unsigned long addr,
+			       unsigned long data)
+{
+	return -EINVAL;
+}
+
+static inline void ptrace_disable(struct task_struct *child)
+{
+}
+
+#endif
diff --git a/arch/lkl/include/asm/vmlinux.lds.h b/arch/lkl/include/asm/vmlinux.lds.h
new file mode 100644
index 0000000..392c94a
--- /dev/null
+++ b/arch/lkl/include/asm/vmlinux.lds.h
@@ -0,0 +1,15 @@
+#ifndef _LKL_VMLINUX_LDS_H
+#define _LKL_VMLINUX_LDS_H
+
+#ifdef __MINGW32__
+#define VMLINUX_SYMBOL(sym) _##sym
+#define RODATA_SECTION .rdata
+#endif
+
+#include <asm-generic/vmlinux.lds.h>
+
+#ifndef RODATA_SECTION
+#define RODATA_SECTION .rodata
+#endif
+
+#endif
diff --git a/arch/lkl/include/uapi/asm/Kbuild b/arch/lkl/include/uapi/asm/Kbuild
new file mode 100644
index 0000000..cfa727b
--- /dev/null
+++ b/arch/lkl/include/uapi/asm/Kbuild
@@ -0,0 +1,38 @@
+# UAPI Header export list
+include include/uapi/asm-generic/Kbuild.asm
+
+generic-y += auxvec.h
+generic-y += byteorder.h
+generic-y += elf.h
+generic-y += errno.h
+generic-y += fcntl.h
+generic-y += ioctl.h
+generic-y += ioctls.h
+generic-y += ipcbuf.h
+generic-y += kvm_para.h
+generic-y += mman.h
+generic-y += msgbuf.h
+generic-y += param.h
+generic-y += poll.h
+generic-y += posix_types.h
+generic-y += ptrace.h
+generic-y += resource.h
+generic-y += sembuf.h
+generic-y += setup.h
+generic-y += shmbuf.h
+generic-y += shmparam.h
+generic-y += siginfo.h
+generic-y += signal.h
+generic-y += socket.h
+generic-y += sockios.h
+generic-y += stat.h
+generic-y += statfs.h
+generic-y += swab.h
+generic-y += termbits.h
+generic-y += termios.h
+generic-y += timex.h
+generic-y += types.h
+generic-y += unistd.h
+
+# no header-y since we need special user headers handling
+# see arch/lkl/script/headers.py
diff --git a/arch/lkl/include/uapi/asm/bitsperlong.h b/arch/lkl/include/uapi/asm/bitsperlong.h
new file mode 100644
index 0000000..12b522d
--- /dev/null
+++ b/arch/lkl/include/uapi/asm/bitsperlong.h
@@ -0,0 +1,12 @@
+#ifndef _ASM_UAPI_LKL_AUTOCONF_H
+#define _ASM_UAPI_LKL_AUTOCONF_H
+
+#ifdef CONFIG_64BIT
+#define __BITS_PER_LONG 64
+#else
+#define __BITS_PER_LONG 32
+#endif
+
+#define __ARCH_WANT_STAT64
+
+#endif /* _ASM_UAPI_LKL_TARGET_H */
diff --git a/arch/lkl/include/uapi/asm/sigcontext.h b/arch/lkl/include/uapi/asm/sigcontext.h
new file mode 100644
index 0000000..99b2d53
--- /dev/null
+++ b/arch/lkl/include/uapi/asm/sigcontext.h
@@ -0,0 +1,14 @@
+#ifndef _ASM_UAPI_LKL_SIGCONTEXT_H
+#define _ASM_UAPI_LKL_SIGCONTEXT_H
+
+#include <asm/ptrace.h>
+
+struct pt_regs {
+};
+
+struct sigcontext {
+	struct pt_regs regs;
+	unsigned long oldmask;
+};
+
+#endif
diff --git a/arch/lkl/kernel/asm-offsets.c b/arch/lkl/kernel/asm-offsets.c
new file mode 100644
index 0000000..9e26311
--- /dev/null
+++ b/arch/lkl/kernel/asm-offsets.c
@@ -0,0 +1 @@
+/* Dummy asm-offsets.c file. Required by kbuild and ready to be used - hint! */
diff --git a/arch/lkl/kernel/misc.c b/arch/lkl/kernel/misc.c
new file mode 100644
index 0000000..44d4736
--- /dev/null
+++ b/arch/lkl/kernel/misc.c
@@ -0,0 +1,57 @@
+#include <linux/kallsyms.h>
+#include <linux/module.h>
+#include <linux/sched.h>
+#include <linux/seq_file.h>
+#include <asm/ptrace.h>
+#include <asm/host_ops.h>
+
+void dump_stack(void)
+{
+	unsigned long dummy;
+	unsigned long *stack = &dummy;
+	unsigned long addr;
+
+	pr_info("Call Trace:\n");
+	while (((long)stack & (THREAD_SIZE - 1)) != 0) {
+		addr = *stack;
+		if (__kernel_text_address(addr)) {
+			pr_info("%p:  [<%08lx>]", stack, addr);
+			print_symbol(KERN_CONT " %s", addr);
+			pr_cont("\n");
+		}
+		stack++;
+	}
+	pr_info("\n");
+}
+
+void show_regs(struct pt_regs *regs)
+{
+}
+
+#ifdef CONFIG_PROC_FS
+static void *cpuinfo_start(struct seq_file *m, loff_t *pos)
+{
+	return NULL;
+}
+
+static void *cpuinfo_next(struct seq_file *m, void *v, loff_t *pos)
+{
+	return NULL;
+}
+
+static void cpuinfo_stop(struct seq_file *m, void *v)
+{
+}
+
+static int show_cpuinfo(struct seq_file *m, void *v)
+{
+	return 0;
+}
+
+const struct seq_operations cpuinfo_op = {
+	.start	= cpuinfo_start,
+	.next	= cpuinfo_next,
+	.stop	= cpuinfo_stop,
+	.show	= show_cpuinfo,
+};
+#endif
diff --git a/arch/lkl/kernel/vmlinux.lds.S b/arch/lkl/kernel/vmlinux.lds.S
new file mode 100644
index 0000000..cf96922
--- /dev/null
+++ b/arch/lkl/kernel/vmlinux.lds.S
@@ -0,0 +1,45 @@
+#include <asm/vmlinux.lds.h>
+#include <asm/thread_info.h>
+#include <asm/page.h>
+#include <asm/cache.h>
+
+OUTPUT_FORMAT(CONFIG_OUTPUT_FORMAT)
+
+VMLINUX_SYMBOL(jiffies) = VMLINUX_SYMBOL(jiffies_64);
+
+SECTIONS
+{
+	VMLINUX_SYMBOL(__init_begin) = .;
+	HEAD_TEXT_SECTION
+	INIT_TEXT_SECTION(PAGE_SIZE)
+	INIT_DATA_SECTION(16)
+	PERCPU_SECTION(L1_CACHE_BYTES)
+	VMLINUX_SYMBOL(__init_end) = .;
+
+	VMLINUX_SYMBOL(_stext) = .;
+	VMLINUX_SYMBOL(_text) = . ;
+	VMLINUX_SYMBOL(text) = . ;
+	.text      :
+	{
+		TEXT_TEXT
+		SCHED_TEXT
+		LOCK_TEXT
+	}
+	VMLINUX_SYMBOL(_etext) = .;
+
+	VMLINUX_SYMBOL(_sdata) = .;
+	RO_DATA_SECTION(PAGE_SIZE)
+	RW_DATA_SECTION(L1_CACHE_BYTES, PAGE_SIZE, THREAD_SIZE)
+	VMLINUX_SYMBOL(_edata) = .;
+
+	EXCEPTION_TABLE(16)
+	NOTES
+
+	BSS_SECTION(0, 0, 0)
+	VMLINUX_SYMBOL(_end) = .;
+
+	STABS_DEBUG
+	DWARF_DEBUG
+
+	DISCARDS
+}
-- 
2.1.0

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1261915

FromRichard Weinberger <richard.weinberger@gmail.com>
Date2015-11-03 22:50 +0100
Message-ID<qqRCO-8it-1@gated-at.bofh.it>
In reply to#1261858
On Tue, Nov 3, 2015 at 9:20 PM, Octavian Purdila
<octavian.purdila@intel.com> wrote:
> LKL (Linux Kernel Library) is aiming to allow reusing the Linux kernel code
> as extensively as possible with minimal effort and reduced maintenance
> overhead.
>
> Examples of how LKL can be used are: creating userspace applications
> (running on Linux and other operating systems) that can read or write Linux
> filesystems or can use the Linux networking stack, creating kernel drivers
> for other operating systems that can read Linux filesystems, bootloaders
> support for reading/writing Linux filesystems, etc.
>
> With LKL, the kernel code is compiled into an object file that can be
> directly linked by applications. The API offered by LKL is based on the
> Linux system call interface.
>
> LKL is implemented as an architecture port in arch/lkl. It relies on host
> operations defined by the application or a host library (tools/lkl/lib).
>
> The latest LKL version can be found at git@github.com:lkl/linux.git

Or more copy&paste friendly: https://github.com/lkl/linux.git

> FAQ
> ===
>
> Q: How is LKL different from UML?
> A: UML provides a full OS environment (e.g. user/kernel separation, user
> processes) and also has requirements (a filesystem, processes, etc.) that
> makes it hard to use it for standalone applications. UML also relies
> heavily on Linux hosts. On the other hand LKL is designed to be linked
> directly with the application and hence does not have user/kernel
> separation which makes it easier to use it in standalone applications.

So, this is a "liblinux" where applications are directly linked
against the kernel.
IOW system calls are plain function calls into the kernel?

This eliminates UML's most problematic areas, system call handling via ptrace()
and virtual memory management via SIGSEGV. :-)

> Q: How is LKL different from LibOS?
> A: LibOS re-implements high-level kernel APIs for timers, softirqs,
> scheduling, sysctl, SLAB/SLUB, etc. LKL behaves like any arch port,
> implementing the arch level operations requested by the Linux kernel. LKL
> also offers a host interface so that support for multiple hosts can be
> easily implemented.

Yeah, these re-implementations are what I find most worrisome about LibOS.

>
> Building LKL the host library and LKL applications
> ==================================================
>
> % cd tools/lkl
> % make
>
> will build LKL as a object file, it will install it in tools/lkl/lib together
> with the headers files in tools/lkl/include then will build the host library,
> tests and a few of application examples:
>
> * tests/boot - a simple applications that uses LKL and exercises the basic
> LKL APIs
>
> * fs2tar - a tool that converts a filesystem image to a tar archive
>
> * cptofs/cpfromfs - a tool that copies files to/from a filesystem image

Seeing forward to have a libguestfs port. :-)

Is LKL strictly single threaded?

-- 
Thanks,
//richard
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1261939

From"Richard W.M. Jones" <rjones@redhat.com>
Date2015-11-03 23:50 +0100
Message-ID<qqSyS-sc-7@gated-at.bofh.it>
In reply to#1261915
On Tue, Nov 03, 2015 at 10:40:29PM +0100, Richard Weinberger wrote:
> On Tue, Nov 3, 2015 at 9:20 PM, Octavian Purdila
> <octavian.purdila@intel.com> wrote:
> > LKL (Linux Kernel Library) is aiming to allow reusing the Linux kernel code
> > as extensively as possible with minimal effort and reduced maintenance
> > overhead.
> >
> > Examples of how LKL can be used are: creating userspace applications
> > (running on Linux and other operating systems) that can read or write Linux
> > filesystems or can use the Linux networking stack, creating kernel drivers
> > for other operating systems that can read Linux filesystems, bootloaders
> > support for reading/writing Linux filesystems, etc.
> >
> > With LKL, the kernel code is compiled into an object file that can be
> > directly linked by applications. The API offered by LKL is based on the
> > Linux system call interface.
> >
> > LKL is implemented as an architecture port in arch/lkl. It relies on host
> > operations defined by the application or a host library (tools/lkl/lib).
> >
> > The latest LKL version can be found at git@github.com:lkl/linux.git
> 
> Or more copy&paste friendly: https://github.com/lkl/linux.git
> 
> > FAQ
> > ===
> >
> > Q: How is LKL different from UML?
> > A: UML provides a full OS environment (e.g. user/kernel separation, user
> > processes) and also has requirements (a filesystem, processes, etc.) that
> > makes it hard to use it for standalone applications. UML also relies
> > heavily on Linux hosts. On the other hand LKL is designed to be linked
> > directly with the application and hence does not have user/kernel
> > separation which makes it easier to use it in standalone applications.
> 
> So, this is a "liblinux" where applications are directly linked
> against the kernel.
> IOW system calls are plain function calls into the kernel?
> 
> This eliminates UML's most problematic areas, system call handling via ptrace()
> and virtual memory management via SIGSEGV. :-)
> 
> > Q: How is LKL different from LibOS?
> > A: LibOS re-implements high-level kernel APIs for timers, softirqs,
> > scheduling, sysctl, SLAB/SLUB, etc. LKL behaves like any arch port,
> > implementing the arch level operations requested by the Linux kernel. LKL
> > also offers a host interface so that support for multiple hosts can be
> > easily implemented.
> 
> Yeah, these re-implementations are what I find most worrisome about LibOS.
> 
> >
> > Building LKL the host library and LKL applications
> > ==================================================
> >
> > % cd tools/lkl
> > % make
> >
> > will build LKL as a object file, it will install it in tools/lkl/lib together
> > with the headers files in tools/lkl/include then will build the host library,
> > tests and a few of application examples:
> >
> > * tests/boot - a simple applications that uses LKL and exercises the basic
> > LKL APIs
> >
> > * fs2tar - a tool that converts a filesystem image to a tar archive
> >
> > * cptofs/cpfromfs - a tool that copies files to/from a filesystem image
> 
> Seeing forward to have a libguestfs port. :-)

Thanks - I was keeping an eye on libos (and on the NetBSD rump kernel
stuff before), ready to integrate them into libguestfs as soon as they
offered filesystem access.

It's easy to write a libguestfs-compatible backend, which brings all
the virt-* tools from libguestfs to the new code.  The UML one looks
like this:

https://github.com/libguestfs/libguestfs/blob/master/src/launch-uml.c

I'm dubious that a lib-based approach could support LVM, partioning,
ntfs-3g, qcow2, vmdk and all the other libguestfs stuff that relies on
userspace tools + qemu as well as just the kernel drivers.
Nevertheless a fast subset of libguestfs supporting just kernel
filesystem drivers could be useful.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-top is 'top' for virtual machines.  Tiny program with many
powerful monitoring features, net stats, disk stats, logging, etc.
http://people.redhat.com/~rjones/virt-top
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1261958

FromOctavian Purdila <octavian.purdila@intel.com>
Date2015-11-04 00:30 +0100
Message-ID<qqTbz-V1-1@gated-at.bofh.it>
In reply to#1261939
On Wed, Nov 4, 2015 at 12:45 AM, Richard W.M. Jones <rjones@redhat.com> wrote:
> On Tue, Nov 03, 2015 at 10:40:29PM +0100, Richard Weinberger wrote:
>> On Tue, Nov 3, 2015 at 9:20 PM, Octavian Purdila
>> <octavian.purdila@intel.com> wrote:
>> > LKL (Linux Kernel Library) is aiming to allow reusing the Linux kernel code
>> > as extensively as possible with minimal effort and reduced maintenance
>> > overhead.
>> >
>> > Examples of how LKL can be used are: creating userspace applications
>> > (running on Linux and other operating systems) that can read or write Linux
>> > filesystems or can use the Linux networking stack, creating kernel drivers
>> > for other operating systems that can read Linux filesystems, bootloaders
>> > support for reading/writing Linux filesystems, etc.
>> >
>> > With LKL, the kernel code is compiled into an object file that can be
>> > directly linked by applications. The API offered by LKL is based on the
>> > Linux system call interface.
>> >
>> > LKL is implemented as an architecture port in arch/lkl. It relies on host
>> > operations defined by the application or a host library (tools/lkl/lib).
>> >
>> > The latest LKL version can be found at git@github.com:lkl/linux.git
>>
>> Or more copy&paste friendly: https://github.com/lkl/linux.git
>>
>> > FAQ
>> > ===
>> >
>> > Q: How is LKL different from UML?
>> > A: UML provides a full OS environment (e.g. user/kernel separation, user
>> > processes) and also has requirements (a filesystem, processes, etc.) that
>> > makes it hard to use it for standalone applications. UML also relies
>> > heavily on Linux hosts. On the other hand LKL is designed to be linked
>> > directly with the application and hence does not have user/kernel
>> > separation which makes it easier to use it in standalone applications.
>>
>> So, this is a "liblinux" where applications are directly linked
>> against the kernel.
>> IOW system calls are plain function calls into the kernel?
>>
>> This eliminates UML's most problematic areas, system call handling via ptrace()
>> and virtual memory management via SIGSEGV. :-)
>>
>> > Q: How is LKL different from LibOS?
>> > A: LibOS re-implements high-level kernel APIs for timers, softirqs,
>> > scheduling, sysctl, SLAB/SLUB, etc. LKL behaves like any arch port,
>> > implementing the arch level operations requested by the Linux kernel. LKL
>> > also offers a host interface so that support for multiple hosts can be
>> > easily implemented.
>>
>> Yeah, these re-implementations are what I find most worrisome about LibOS.
>>
>> >
>> > Building LKL the host library and LKL applications
>> > ==================================================
>> >
>> > % cd tools/lkl
>> > % make
>> >
>> > will build LKL as a object file, it will install it in tools/lkl/lib together
>> > with the headers files in tools/lkl/include then will build the host library,
>> > tests and a few of application examples:
>> >
>> > * tests/boot - a simple applications that uses LKL and exercises the basic
>> > LKL APIs
>> >
>> > * fs2tar - a tool that converts a filesystem image to a tar archive
>> >
>> > * cptofs/cpfromfs - a tool that copies files to/from a filesystem image
>>
>> Seeing forward to have a libguestfs port. :-)
>
> Thanks - I was keeping an eye on libos (and on the NetBSD rump kernel
> stuff before), ready to integrate them into libguestfs as soon as they
> offered filesystem access.
>
> It's easy to write a libguestfs-compatible backend, which brings all
> the virt-* tools from libguestfs to the new code.  The UML one looks
> like this:
>
> https://github.com/libguestfs/libguestfs/blob/master/src/launch-uml.c
>

Thanks for the pointers Richard, I am going to take a look at it.

>
> I'm dubious that a lib-based approach could support LVM, partioning,
> ntfs-3g, qcow2, vmdk and all the other libguestfs stuff that relies on
> userspace tools + qemu as well as just the kernel drivers.
> Nevertheless a fast subset of libguestfs supporting just kernel
> filesystem drivers could be useful.
>

LKL uses the full Linux I/O stack and I think LVM and partitioning
should work out of the box. Adding support for qcow2 and vmdk should
be possible as well. ntfs-3g might be problematic.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1262275

FromAustin S Hemmelgarn <ahferroin7@gmail.com>
Date2015-11-04 14:30 +0100
Message-ID<qr6iu-ZS-5@gated-at.bofh.it>
In reply to#1261958

[Multipart message — attachments visible in raw view] — view raw

On 2015-11-03 18:24, Octavian Purdila wrote:
> On Wed, Nov 4, 2015 at 12:45 AM, Richard W.M. Jones <rjones@redhat.com> wrote:
>> I'm dubious that a lib-based approach could support LVM, partioning,
>> ntfs-3g, qcow2, vmdk and all the other libguestfs stuff that relies on
>> userspace tools + qemu as well as just the kernel drivers.
>> Nevertheless a fast subset of libguestfs supporting just kernel
>> filesystem drivers could be useful.
>
> LKL uses the full Linux I/O stack and I think LVM and partitioning
> should work out of the box. Adding support for qcow2 and vmdk should
> be possible as well. ntfs-3g might be problematic.

Partitioning will work fine based on what you say.  MD using the old 
metadata and automatic assembly should also work fine (assuming there is 
some way to tell the library to simulate running initcalls).  DM (and by 
extension LVM, which is a bunch of userspace stuff on top of regular DM) 
and new style MD both require userspace tools to configure and interact 
with, this could be handled in two different ways:
1. Update the LVM and MD tools so they can be built as libraries and
    work directly with LKL.
2. Provide some wrapper functions to emulate dmsetup, lvm, and mdadm as
    distinct library calls.
Of these, the first option is likely to be the best for long-term 
support, but the second is probably going to be easier to code quickly.

QCOW2 and VMDK are both VM disk formats, and while I would love to see a 
driver treat them (and VDI, and VHD) like regular disk images on Linux 
in general, that will take some effort to implement properly.

NTFS-3G is a FUSE based filesystem driver, so that kind of functionality 
would probably need to be implemented in the application itself 
(although having some way to have the app just link to it instead would 
be absolutely wonderful).

[toc] | [prev] | [next] | [standalone]

#1262290

From"Richard W.M. Jones" <rjones@redhat.com>
Date2015-11-04 15:00 +0100
Message-ID<qr6Lw-19D-9@gated-at.bofh.it>
In reply to#1261958
On Wed, Nov 04, 2015 at 01:24:03AM +0200, Octavian Purdila wrote:
> Thanks for the pointers Richard, I am going to take a look at it.

Now I've had a chance to look at some of the example LKL tools, here's
what this actually involves.  It's not actually a great deal of work,
it could probably be done in a day or two, but see my question about
`lkl_sys_*' below.

libguestfs (the library part) needs to talk over an RPC connection to
its daemon.  See diagram here:

http://libguestfs.org/guestfs-internals.1.html

The code in src/launch-{direct,libvirt,uml,...}.c sets up that
connection and runs the daemon -- normally inside a qemu wrapper, but
it could be inside UML.  For LKL I think it should just fork the
daemon directly.

The daemon would then be linked to LKL.

So really what's needed is a src/launch-lkl.c probably modelled after
one of these current backends:

https://github.com/libguestfs/libguestfs/blob/master/src/launch-uml.c
https://github.com/libguestfs/libguestfs/blob/master/src/launch-unix.c

and then recompile the daemon to link to LKL:

https://github.com/libguestfs/libguestfs/tree/master/daemon

and pass the list of disk images to the daemon, probably best to do
that on the guestfsd command line.

My only problem here: you can't just link to daemon to LKL, do you
have to change all of the system calls from `foo' to `lkl_sys_foo'?
That's an awful lot of #ifdefs ...

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-top is 'top' for virtual machines.  Tiny program with many
powerful monitoring features, net stats, disk stats, logging, etc.
http://people.redhat.com/~rjones/virt-top
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1262306

FromOctavian Purdila <octavian.purdila@intel.com>
Date2015-11-04 15:30 +0100
Message-ID<qr7ex-1AQ-7@gated-at.bofh.it>
In reply to#1262290
On Wed, Nov 4, 2015 at 3:50 PM, Richard W.M. Jones <rjones@redhat.com> wrote:
> On Wed, Nov 04, 2015 at 01:24:03AM +0200, Octavian Purdila wrote:
>> Thanks for the pointers Richard, I am going to take a look at it.
>
> Now I've had a chance to look at some of the example LKL tools, here's
> what this actually involves.  It's not actually a great deal of work,
> it could probably be done in a day or two, but see my question about
> `lkl_sys_*' below.
>
> libguestfs (the library part) needs to talk over an RPC connection to
> its daemon.  See diagram here:
>
> http://libguestfs.org/guestfs-internals.1.html
>
> The code in src/launch-{direct,libvirt,uml,...}.c sets up that
> connection and runs the daemon -- normally inside a qemu wrapper, but
> it could be inside UML.  For LKL I think it should just fork the
> daemon directly.
>
> The daemon would then be linked to LKL.
>
> So really what's needed is a src/launch-lkl.c probably modelled after
> one of these current backends:
>
> https://github.com/libguestfs/libguestfs/blob/master/src/launch-uml.c
> https://github.com/libguestfs/libguestfs/blob/master/src/launch-unix.c
>
> and then recompile the daemon to link to LKL:
>
> https://github.com/libguestfs/libguestfs/tree/master/daemon
>
> and pass the list of disk images to the daemon, probably best to do
> that on the guestfsd command line.
>
> My only problem here: you can't just link to daemon to LKL, do you
> have to change all of the system calls from `foo' to `lkl_sys_foo'?
> That's an awful lot of #ifdefs ...
>

We could redefine the syscalls/libc symbols to call lkl_sys_ functions
in launch-lkl, e.g.:

int opendir(const char *path)
{
   return lkl_opendir(new_path)
}
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1264670

FromRichard Weinberger <richard@nod.at>
Date2015-11-07 01:40 +0100
Message-ID<qrZHX-3on-1@gated-at.bofh.it>
In reply to#1262306
Am 04.11.2015 um 15:15 schrieb Octavian Purdila:
> We could redefine the syscalls/libc symbols to call lkl_sys_ functions
> in launch-lkl, e.g.:
> 
> int opendir(const char *path)
> {
>    return lkl_opendir(new_path)
> }

To get a better feeling how LKL behaves I've started with a tool
to mount any Linux filesystem by FUSE.
I.e. such that we can finally automount without root and bugs in filesystem
code won't hurt that much.

lkl_sys_fstatat64() uses the type struct lkl_stat64. Where is it defined?
git grep is unable to locate it.
At least it seems to be incompatible with my local struct stat.

And why is there no lkl_sys_openat() syscall?

Thanks,
//richard
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1264748

From"Richard W.M. Jones" <rjones@redhat.com>
Date2015-11-07 08:20 +0100
Message-ID<qs5X4-7Dj-3@gated-at.bofh.it>
In reply to#1264670
On Sat, Nov 07, 2015 at 01:35:36AM +0100, Richard Weinberger wrote:
> Am 04.11.2015 um 15:15 schrieb Octavian Purdila:
> > We could redefine the syscalls/libc symbols to call lkl_sys_ functions
> > in launch-lkl, e.g.:
> > 
> > int opendir(const char *path)
> > {
> >    return lkl_opendir(new_path)
> > }
> 
> To get a better feeling how LKL behaves I've started with a tool
> to mount any Linux filesystem by FUSE.
> I.e. such that we can finally automount without root and bugs in filesystem
> code won't hurt that much.

guestmount already does this:

http://libguestfs.org/guestmount.1.html

By porting a small amount of code from the daemon/ directory, it could
do it using lkl too.  See:

http://www.gossamer-threads.com/lists/linux/kernel/2296116#2296116

Rich.

> lkl_sys_fstatat64() uses the type struct lkl_stat64. Where is it defined?
> git grep is unable to locate it.
> At least it seems to be incompatible with my local struct stat.
> 
> And why is there no lkl_sys_openat() syscall?
> 
> Thanks,
> //richard

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
Fedora Windows cross-compiler. Compile Windows programs, test, and
build Windows installers. Over 100 libraries supported.
http://fedoraproject.org/wiki/MinGW
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1264805

From"Richard W.M. Jones" <rjones@redhat.com>
Date2015-11-07 11:50 +0100
Message-ID<qs9eh-18b-1@gated-at.bofh.it>
In reply to#1264670
I just pushed a (very early) WIP branch that contains changes to
libguestfs to add an LKL backend:

  https://github.com/rwmjones/libguestfs/tree/lkl

Read the README file in the libguestfs sources before starting,
followed by the instructions in the commit message:

  https://github.com/rwmjones/libguestfs/commit/e38525f0b984d0a426f3348d95f2033673d4eaa4

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-df lists disk usage of guests without needing to install any
software inside the virtual machine.  Supports Linux and Windows.
http://people.redhat.com/~rjones/virt-df/
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1265843

FromOctavian Purdila <octavian.purdila@intel.com>
Date2015-11-09 17:40 +0100
Message-ID<qsXE6-pE-27@gated-at.bofh.it>
In reply to#1264805
On Sat, Nov 7, 2015 at 12:48 PM, Richard W.M. Jones <rjones@redhat.com> wrote:
>
> I just pushed a (very early) WIP branch that contains changes to
> libguestfs to add an LKL backend:
>
>   https://github.com/rwmjones/libguestfs/tree/lkl
>
> Read the README file in the libguestfs sources before starting,
> followed by the instructions in the commit message:
>
>   https://github.com/rwmjones/libguestfs/commit/e38525f0b984d0a426f3348d95f2033673d4eaa4
>

Hi Richard,

Thanks for this, I was able to replicate it locally.

I started working on adding a new library, liblkl-redirect.a, that
redefines common libc symbols to use lkl. We then can link the daemon
with this lib and lkl to avoid ugly ifdefs in the daemon code.

Thanks,
Tavi
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1264965

FromOctavian Purdila <octavian.purdila@intel.com>
Date2015-11-08 05:20 +0100
Message-ID<qspCp-3nA-5@gated-at.bofh.it>
In reply to#1264670
On Sat, Nov 7, 2015 at 2:35 AM, Richard Weinberger <richard@nod.at> wrote:
> Am 04.11.2015 um 15:15 schrieb Octavian Purdila:
>> We could redefine the syscalls/libc symbols to call lkl_sys_ functions
>> in launch-lkl, e.g.:
>>
>> int opendir(const char *path)
>> {
>>    return lkl_opendir(new_path)
>> }
>
> To get a better feeling how LKL behaves I've started with a tool
> to mount any Linux filesystem by FUSE.
> I.e. such that we can finally automount without root and bugs in filesystem
> code won't hurt that much.
>
> lkl_sys_fstatat64() uses the type struct lkl_stat64. Where is it defined?
> git grep is unable to locate it.
> At least it seems to be incompatible with my local struct stat.
>
> And why is there no lkl_sys_openat() syscall?
>
> Thanks,
> //richard
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1264966

FromOctavian Purdila <octavian.purdila@intel.com>
Date2015-11-08 05:40 +0100
Message-ID<qspVL-3we-3@gated-at.bofh.it>
In reply to#1264670
On Sat, Nov 7, 2015 at 2:35 AM, Richard Weinberger <richard@nod.at> wrote:
> Am 04.11.2015 um 15:15 schrieb Octavian Purdila:
>> We could redefine the syscalls/libc symbols to call lkl_sys_ functions
>> in launch-lkl, e.g.:
>>
>> int opendir(const char *path)
>> {
>>    return lkl_opendir(new_path)
>> }
>
> To get a better feeling how LKL behaves I've started with a tool
> to mount any Linux filesystem by FUSE.
> I.e. such that we can finally automount without root and bugs in filesystem
> code won't hurt that much.
>

Hi Richard,

I finished coding mine up yesterday :) I've just pushed it to github
if you want to take a look at it (together with some small fixes).

> lkl_sys_fstatat64() uses the type struct lkl_stat64. Where is it defined?
> git grep is unable to locate it.
> At least it seems to be incompatible with my local struct stat.
>

When doing the build in tools/lkl the LKL headers are installed in
include/lkl. You should find it in there:

$:~/src/linux/tools/lkl$ find include/ -type f | xargs grep lkl_stat64
include/lkl/asm-generic/stat.h:struct lkl_stat64 {

> And why is there no lkl_sys_openat() syscall?
>

Didn't get to test it hence I didn't add it to the API yet, as many
other system calls.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1261961

FromHajime Tazaki <thehajime@gmail.com>
Date2015-11-04 00:30 +0100
Message-ID<qqTbA-V1-19@gated-at.bofh.it>
In reply to#1261939
At Tue, 3 Nov 2015 22:45:45 +0000,
Richard W.M. Jones wrote:

> > > * cptofs/cpfromfs - a tool that copies files to/from a filesystem image
> > 
> > Seeing forward to have a libguestfs port. :-)
> 
> Thanks - I was keeping an eye on libos (and on the NetBSD rump kernel
> stuff before), ready to integrate them into libguestfs as soon as they
> offered filesystem access.

I've been working on fs support on libos recently during
the integration with rump kernel _hypercall_, though it's
still in the middle (but open(2) in a specific condition
works fine at least).

https://github.com/libos-nuse/net-next-nuse/tree/rump-hypcall

I would expect to see more concrete patchset in near future.

-- Hajime
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1261950

FromOctavian Purdila <octavian.purdila@intel.com>
Date2015-11-04 00:10 +0100
Message-ID<qqSSe-O3-23@gated-at.bofh.it>
In reply to#1261915
On Tue, Nov 3, 2015 at 11:40 PM, Richard Weinberger
<richard.weinberger@gmail.com> wrote:

Hi Richard,

> On Tue, Nov 3, 2015 at 9:20 PM, Octavian Purdila
> <octavian.purdila@intel.com> wrote:
>> LKL (Linux Kernel Library) is aiming to allow reusing the Linux kernel code
>> as extensively as possible with minimal effort and reduced maintenance
>> overhead.
>>
>> Examples of how LKL can be used are: creating userspace applications
>> (running on Linux and other operating systems) that can read or write Linux
>> filesystems or can use the Linux networking stack, creating kernel drivers
>> for other operating systems that can read Linux filesystems, bootloaders
>> support for reading/writing Linux filesystems, etc.
>>
>> With LKL, the kernel code is compiled into an object file that can be
>> directly linked by applications. The API offered by LKL is based on the
>> Linux system call interface.
>>
>> LKL is implemented as an architecture port in arch/lkl. It relies on host
>> operations defined by the application or a host library (tools/lkl/lib).
>>
>> The latest LKL version can be found at git@github.com:lkl/linux.git
>
> Or more copy&paste friendly: https://github.com/lkl/linux.git
>
>> FAQ
>> ===
>>
>> Q: How is LKL different from UML?
>> A: UML provides a full OS environment (e.g. user/kernel separation, user
>> processes) and also has requirements (a filesystem, processes, etc.) that
>> makes it hard to use it for standalone applications. UML also relies
>> heavily on Linux hosts. On the other hand LKL is designed to be linked
>> directly with the application and hence does not have user/kernel
>> separation which makes it easier to use it in standalone applications.
>
> So, this is a "liblinux" where applications are directly linked
> against the kernel.
> IOW system calls are plain function calls into the kernel?
>

More like "thread" calls. All system calls are executed in a dedicate
(kernel) thread to avoid race conditions with the "interrupt" path.

> This eliminates UML's most problematic areas, system call handling via ptrace()
> and virtual memory management via SIGSEGV. :-)
>

:)

>> Q: How is LKL different from LibOS?
>> A: LibOS re-implements high-level kernel APIs for timers, softirqs,
>> scheduling, sysctl, SLAB/SLUB, etc. LKL behaves like any arch port,
>> implementing the arch level operations requested by the Linux kernel. LKL
>> also offers a host interface so that support for multiple hosts can be
>> easily implemented.
>
> Yeah, these re-implementations are what I find most worrisome about LibOS.
>
>>
>> Building LKL the host library and LKL applications
>> ==================================================
>>
>> % cd tools/lkl
>> % make
>>
>> will build LKL as a object file, it will install it in tools/lkl/lib together
>> with the headers files in tools/lkl/include then will build the host library,
>> tests and a few of application examples:
>>
>> * tests/boot - a simple applications that uses LKL and exercises the basic
>> LKL APIs
>>
>> * fs2tar - a tool that converts a filesystem image to a tar archive
>>
>> * cptofs/cpfromfs - a tool that copies files to/from a filesystem image
>
> Seeing forward to have a libguestfs port. :-)
>
> Is LKL strictly single threaded?
>

At this point yes. SMP support is on my todo list though :)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

Back to top | Article view | linux.kernel

csiph-web