* Re: [PATCH] bootup: Add built-in kernel command line for x86
From: Tim Bird @ 2008-08-06 23:00 UTC (permalink / raw)
To: H. Peter Anvin
Cc: Robert Schwebel, linux kernel, linux-embedded, Matt Mackall,
Thomas Gleixner
In-Reply-To: <489A2A24.6010400@zytor.com>
H. Peter Anvin wrote:
> Tim Bird wrote:
>> The only thing novel thing I'm adding here is the addition of
>> the leading '!' to allow for an override. This is needed
>> in some x86 cases I'm familiar with, but I've haven't seen
>> any cases where it would be useful for other arches.
>> (not to say they don't exist - I just haven't seen them.)
>>
>
> Note that it could just as easily be done with a CONFIG_CMDLINE_OVERRIDE
> option, since the initial reason for a magic character was to be able to
> provide both prefix and suffix splicing.
Agreed.
>
> CONFIG_CMDLINE_OVERRIDE is probably more palatable to other architectures.
I'd be OK implementing it with an option, rather than a magic char.
I was trying to avoid adding too many options, since many kernel
developers prefer fewer options where possible. But the magic
char makes the code less straightforward.
If we ever move towards supporting both prefix and suffice splicing (or
even complicated in-the-middle splicing), then the magic char is
easier to develop into that. But so far, I can only come up with
reasonable cases for append and override, and I don't want to add
superfluous handling for non-existent use cases.
-- Tim
=============================
Tim Bird
Architecture Group Chair, CE Linux Forum
Senior Staff Engineer, Sony Corporation of America
=============================
^ permalink raw reply
* Re: [PATCH] bootup: Add built-in kernel command line for x86
From: Matt Mackall @ 2008-08-06 22:52 UTC (permalink / raw)
To: H. Peter Anvin
Cc: Tim Bird, Robert Schwebel, linux kernel, linux-embedded,
Thomas Gleixner
In-Reply-To: <489A2A24.6010400@zytor.com>
On Wed, 2008-08-06 at 15:48 -0700, H. Peter Anvin wrote:
> Tim Bird wrote:
> >
> > One difficulty is that the other arches' command lines
> > are not currently "broken", so there's no real incentive
> > to change them.
> >
> > The only thing novel thing I'm adding here is the addition of
> > the leading '!' to allow for an override. This is needed
> > in some x86 cases I'm familiar with, but I've haven't seen
> > any cases where it would be useful for other arches.
> > (not to say they don't exist - I just haven't seen them.)
> >
>
> Note that it could just as easily be done with a CONFIG_CMDLINE_OVERRIDE
> option, since the initial reason for a magic character was to be able to
> provide both prefix and suffix splicing.
You're right, I had forgotten about the suffix splicing and my brain is
a bit foggy on what motivated it.
> CONFIG_CMDLINE_OVERRIDE is probably more palatable to other architectures.
Yes, though I doubt we're in danger of introducing any real backwards
compatibility issues with the magic '!' at the beginning.
--
Mathematics is the supreme nostalgia of our time.
^ permalink raw reply
* Re: [PATCH] bootup: Add built-in kernel command line for x86
From: Matt Mackall @ 2008-08-06 22:48 UTC (permalink / raw)
To: Tim Bird; +Cc: linux kernel, linux-embedded, H. Peter Anvin, Thomas Gleixner
In-Reply-To: <489A2627.40908@am.sony.com>
On Wed, 2008-08-06 at 15:31 -0700, Tim Bird wrote:
> Matt Mackall wrote:
> > On Wed, 2008-08-06 at 14:31 -0700, Tim Bird wrote:
> >> The default behavior is to append the boot loader string
> >> to this one. However, there is a mechanism (leading '!')
> >> to force the built-in string to override the boot loader
> >> string.
> >
> > Nice solution.
> >
> > Where is this relative to early boot option checking?
>
> parse_early_param() is right AFTER this in the x86 setup_arch()
> function (in arch/x86/kernel/setup.c). All the other command-line
> handling I could find is after this in init/main.c:start_kernel().
Ok, there are a couple weird outliers outside of that still, but that
should make most people satisfied.
--
Mathematics is the supreme nostalgia of our time.
^ permalink raw reply
* Re: [PATCH] bootup: Add built-in kernel command line for x86
From: H. Peter Anvin @ 2008-08-06 22:48 UTC (permalink / raw)
To: Tim Bird
Cc: Robert Schwebel, linux kernel, linux-embedded, Matt Mackall,
Thomas Gleixner
In-Reply-To: <489A2419.2030900@am.sony.com>
Tim Bird wrote:
>
> One difficulty is that the other arches' command lines
> are not currently "broken", so there's no real incentive
> to change them.
>
> The only thing novel thing I'm adding here is the addition of
> the leading '!' to allow for an override. This is needed
> in some x86 cases I'm familiar with, but I've haven't seen
> any cases where it would be useful for other arches.
> (not to say they don't exist - I just haven't seen them.)
>
Note that it could just as easily be done with a CONFIG_CMDLINE_OVERRIDE
option, since the initial reason for a magic character was to be able to
provide both prefix and suffix splicing.
CONFIG_CMDLINE_OVERRIDE is probably more palatable to other architectures.
-hpa
^ permalink raw reply
* Re: [PATCH] bootup: Add built-in kernel command line for x86
From: Tim Bird @ 2008-08-06 22:31 UTC (permalink / raw)
To: Matt Mackall
Cc: linux kernel, linux-embedded, H. Peter Anvin, Thomas Gleixner
In-Reply-To: <1218060873.7576.2.camel@calx>
Matt Mackall wrote:
> On Wed, 2008-08-06 at 14:31 -0700, Tim Bird wrote:
>> The default behavior is to append the boot loader string
>> to this one. However, there is a mechanism (leading '!')
>> to force the built-in string to override the boot loader
>> string.
>
> Nice solution.
>
> Where is this relative to early boot option checking?
parse_early_param() is right AFTER this in the x86 setup_arch()
function (in arch/x86/kernel/setup.c). All the other command-line
handling I could find is after this in init/main.c:start_kernel().
There is some stuff earlier in the setup_arch() routine about
boot_params, but that looks like it's related to the old(?)
binary data points you can jam into the kernel image. (That is,
it doesn't look like it's related to the command line handling).
-- Tim
=============================
Tim Bird
Architecture Group Chair, CE Linux Forum
Senior Staff Engineer, Sony Corporation of America
=============================
^ permalink raw reply
* Re: [PATCH] bootup: Add built-in kernel command line for x86
From: Tim Bird @ 2008-08-06 22:22 UTC (permalink / raw)
To: Robert Schwebel
Cc: linux kernel, linux-embedded, Matt Mackall, H. Peter Anvin,
Thomas Gleixner
In-Reply-To: <20080806220445.GB10168@pengutronix.de>
Robert Schwebel wrote:
> On Wed, Aug 06, 2008 at 02:31:48PM -0700, Tim Bird wrote:
>> Add support for a built-in command line for x86 architectures.
>> The Kconfig help gives the major rationale for this addition.
>
> If this feature is desired on all architectures, shouldn't it go out of
> arch/?
Different arches handle their command lines differently, but
with some elbow grease (and some buy-in from the different
arch maintainers), we could try unifying the approach here.
One difficulty is that the other arches' command lines
are not currently "broken", so there's no real incentive
to change them.
The only thing novel thing I'm adding here is the addition of
the leading '!' to allow for an override. This is needed
in some x86 cases I'm familiar with, but I've haven't seen
any cases where it would be useful for other arches.
(not to say they don't exist - I just haven't seen them.)
-- Tim
=============================
Tim Bird
Architecture Group Chair, CE Linux Forum
Senior Staff Engineer, Sony Corporation of America
=============================
^ permalink raw reply
* Re: [PATCH] bootup: Add built-in kernel command line for x86
From: Matt Mackall @ 2008-08-06 22:14 UTC (permalink / raw)
To: Tim Bird; +Cc: linux kernel, linux-embedded, H. Peter Anvin, Thomas Gleixner
In-Reply-To: <489A1844.3090502@am.sony.com>
On Wed, 2008-08-06 at 14:31 -0700, Tim Bird wrote:
> The default behavior is to append the boot loader string
> to this one. However, there is a mechanism (leading '!')
> to force the built-in string to override the boot loader
> string.
Nice solution.
Where is this relative to early boot option checking?
--
Mathematics is the supreme nostalgia of our time.
^ permalink raw reply
* Re: [PATCH] bootup: Add built-in kernel command line for x86
From: Robert Schwebel @ 2008-08-06 22:04 UTC (permalink / raw)
To: Tim Bird
Cc: linux kernel, linux-embedded, Matt Mackall, H. Peter Anvin,
Thomas Gleixner
In-Reply-To: <489A1844.3090502@am.sony.com>
On Wed, Aug 06, 2008 at 02:31:48PM -0700, Tim Bird wrote:
> Add support for a built-in command line for x86 architectures.
> The Kconfig help gives the major rationale for this addition.
If this feature is desired on all architectures, shouldn't it go out of
arch/?
rsc
--
Dipl.-Ing. Robert Schwebel | http://www.pengutronix.de
Pengutronix - Linux Solutions for Science and Industry
Handelsregister: Amtsgericht Hildesheim, HRA 2686
Hannoversche Str. 2, 31134 Hildesheim, Germany
Phone: +49-5121-206917-0 | Fax: +49-5121-206917-9
^ permalink raw reply
* [PATCH] bootup: Add built-in kernel command line for x86
From: Tim Bird @ 2008-08-06 21:31 UTC (permalink / raw)
To: linux kernel, linux-embedded, Matt Mackall, H. Peter Anvin,
Thomas Gleixner <>
Add support for a built-in command line for x86 architectures.
The Kconfig help gives the major rationale for this addition.
Note that this option is available for many other arches, and
its use is widespread in embedded projects.
This patch addresses concerns that were raised with an
earlier version, regarding precedence between the built-in
command line and the command line provided by the boot
loader.
See the thread at http://lkml.org/lkml/2006/6/11/115
for details.
The default behavior is to append the boot loader string
to this one. However, there is a mechanism (leading '!')
to force the built-in string to override the boot loader
string.
This implementation covers some important cases mentioned
in the previous thread, namely:
* boot loaders that can't pass args to the kernel
* boot loaders that pass incorrect args to the kernel
* automated testing of kernel command line options,
without having to address lots of different bootloaders
Signed-off-by: Tim Bird <tim.bird@am.sony.com>
---
Note: If you're copied on this, it's because you seemed
interested in this the last time it was submitted.
This particular implementation adds a space to the
front of the command line, in the default case where
the built-in string is empty. I don't think this is a
problem, but comments are welcome. It would be trivial
to remove the extra space, and require people who set
the string to know what they are doing, and add their
own space at the end of the string in the .config.
arch/x86/Kconfig | 24 ++++++++++++++++++++++++
arch/x86/kernel/setup.c | 11 +++++++++++
2 files changed, 35 insertions(+), 0 deletions(-)
diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index 3d0f2b6..63c181e 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -1393,6 +1393,30 @@ config COMPAT_VDSO
If unsure, say Y.
+config CMDLINE
+ string "Initial kernel command string"
+ default ""
+ help
+ On some systems (e.g. embedded ones), there is no way for the
+ boot loader to pass arguments to the kernel. On some systems,
+ the arguments passed by the boot loader are incorrect. For these
+ platforms, you can supply command-line options at build
+ time by entering them here. These will be compiled into the kernel
+ image and used at boot time.
+
+ If the boot loader provides a command line at boot time, it is
+ appended to this string. To have the kernel ignore the boot loader
+ command line, and use ONLY the string specified here, use an
+ exclamation point as the first character of the string.
+ Example: "!root=/dev/hda1 ro"
+
+ In most cases, the command line (whether built-in or provided
+ by the boot loader) should specify the device for the root
+ file system.
+
+ Systems with fully functional boot loaders (i.e. non-embedded)
+ should leave this string blank.
+
endmenu
config ARCH_ENABLE_MEMORY_HOTPLUG
diff --git a/arch/x86/kernel/setup.c b/arch/x86/kernel/setup.c
index 2d88858..298bcee 100644
--- a/arch/x86/kernel/setup.c
+++ b/arch/x86/kernel/setup.c
@@ -223,6 +223,7 @@ unsigned long saved_video_mode;
#define RAMDISK_LOAD_FLAG 0x4000
static char __initdata command_line[COMMAND_LINE_SIZE];
+static char __initdata builtin_cmdline[COMMAND_LINE_SIZE] = CONFIG_CMDLINE;
#if defined(CONFIG_EDD) || defined(CONFIG_EDD_MODULE)
struct edd edd;
@@ -665,6 +666,16 @@ void __init setup_arch(char **cmdline_p)
bss_resource.start = virt_to_phys(&__bss_start);
bss_resource.end = virt_to_phys(&__bss_stop)-1;
+ /* append boot loader cmdline to builtin, unless builtin overrides it */
+ if (builtin_cmdline[0] != '!') {
+ strlcat(builtin_cmdline, " ", COMMAND_LINE_SIZE);
+ strlcat(builtin_cmdline, boot_command_line, COMMAND_LINE_SIZE);
+ strlcpy(boot_command_line, builtin_cmdline, COMMAND_LINE_SIZE);
+ } else {
+ strlcpy(boot_command_line, &builtin_cmdline[1],
+ COMMAND_LINE_SIZE);
+ }
+
strlcpy(command_line, boot_command_line, COMMAND_LINE_SIZE);
*cmdline_p = command_line;
--
1.5.6
^ permalink raw reply related
* Re: Big include file move breaks user mode
From: Kumar Gala @ 2008-08-06 19:21 UTC (permalink / raw)
To: René Rebe
Cc: Sean MacLennan, ppc-dev list, Arnd Bergmann, Linux-Embedded
In-Reply-To: <4899E2FE.6090709@exactcode.de>
On Aug 6, 2008, at 12:44 PM, René Rebe wrote:
>
> Heh, you might also consider using "off the shelf" build systems, such
> as the T2 SDE:
>
> http://t2-project.org
>
> To avoid re-inventing the wheel again and again.
>
> Yours,
>
Whee.. another rootfs build system. Why we can't converge some of
these towards so we have a larger community is beyond me.
- k--
To unsubscribe from this list: send the line "unsubscribe linux-embedded" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [patch 2/4] Configure out file locking features
From: Thomas Petazzoni @ 2008-08-06 13:12 UTC (permalink / raw)
To: J. Bruce Fields
Cc: linux-kernel, linux-embedded, michael, Matt Mackall, matthew,
linux-fsdevel, akpm
In-Reply-To: <20080804181641.GE25940@fieldses.org>
Le Mon, 4 Aug 2008 14:16:41 -0400,
"J. Bruce Fields" <bfields@fieldses.org> a écrit :
> OK by me, but again, why exactly? Since you're replacing the locking
> calls they used by stubs that just return errors, in theory nfs, nfsd,
> gfs2, and the rest should still compile and run, just without locking
> support, right?
You're right, that was stupid. Either should I add the Kconfig
dependencies *OR* add the function stubs, not both. The following patch
implements the second solution. I've checked that NFS, CIFS, GFS2,
OCFS2, AFS and FUSE compile correctly. I've tested NFS only, though.
Here is the new patch. Comments and suggestions welcome.
Sincerly,
Thomas
---
Configure out file locking features
This patch adds the CONFIG_FILE_LOCKING option which allows to remove
support for advisory locks. With this patch enabled, the flock()
system call, the F_GETLK, F_SETLK and F_SETLKW operations of fcntl()
and NFS support are disabled. These features are not necessarly needed
on embedded systems. It allows to save ~11 Kb of kernel code and data:
text data bss dec hex filename
1125436 118764 212992 1457192 163c28 vmlinux.old
1114299 118564 212992 1445855 160fdf vmlinux
-11137 -200 0 -11337 -2C49 +/-
This patch has originally been written by Matt Mackall
<mpm@selenic.com>, and is part of the Linux Tiny project.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Matt Mackall <mpm@selenic.com>
Cc: matthew@wil.cx
Cc: linux-fsdevel@vger.kernel.org
Cc: mpm@selenic.com
Cc: akpm@linux-foundation.org
---
fs/Kconfig | 8 +++++++
fs/Makefile | 3 +-
fs/proc/proc_misc.c | 4 +++
include/linux/fs.h | 55 +++++++++++++++++++++++++++++++++++++++++++++-------
kernel/sys_ni.c | 1
kernel/sysctl.c | 6 ++++-
6 files changed, 68 insertions(+), 9 deletions(-)
Index: linuxdev/fs/Kconfig
===================================================================
--- linuxdev.orig/fs/Kconfig
+++ linuxdev/fs/Kconfig
@@ -419,6 +419,14 @@
bool
default n
+config FILE_LOCKING
+ bool "Enable POSIX file locking API" if EMBEDDED
+ default y
+ help
+ This option enables standard file locking support, required
+ for filesystems like NFS and for the flock() system
+ call. Disabling this option saves about 11k.
+
source "fs/xfs/Kconfig"
source "fs/gfs2/Kconfig"
Index: linuxdev/fs/Makefile
===================================================================
--- linuxdev.orig/fs/Makefile
+++ linuxdev/fs/Makefile
@@ -7,7 +7,7 @@
obj-y := open.o read_write.o file_table.o super.o \
char_dev.o stat.o exec.o pipe.o namei.o fcntl.o \
- ioctl.o readdir.o select.o fifo.o locks.o dcache.o inode.o \
+ ioctl.o readdir.o select.o fifo.o dcache.o inode.o \
attr.o bad_inode.o file.o filesystems.o namespace.o aio.o \
seq_file.o xattr.o libfs.o fs-writeback.o \
pnode.o drop_caches.o splice.o sync.o utimes.o \
@@ -27,6 +27,7 @@
obj-$(CONFIG_SIGNALFD) += signalfd.o
obj-$(CONFIG_TIMERFD) += timerfd.o
obj-$(CONFIG_EVENTFD) += eventfd.o
+obj-$(CONFIG_FILE_LOCKING) += locks.o
obj-$(CONFIG_COMPAT) += compat.o compat_ioctl.o
nfsd-$(CONFIG_NFSD) := nfsctl.o
Index: linuxdev/fs/proc/proc_misc.c
===================================================================
--- linuxdev.orig/fs/proc/proc_misc.c
+++ linuxdev/fs/proc/proc_misc.c
@@ -677,6 +677,7 @@
return proc_calc_metrics(page, start, off, count, eof, len);
}
+#ifdef CONFIG_FILE_LOCKING
static int locks_open(struct inode *inode, struct file *filp)
{
return seq_open(filp, &locks_seq_operations);
@@ -688,6 +689,7 @@
.llseek = seq_lseek,
.release = seq_release,
};
+#endif /* CONFIG_FILE_LOCKING */
static int execdomains_read_proc(char *page, char **start, off_t off,
int count, int *eof, void *data)
@@ -881,7 +883,9 @@
#ifdef CONFIG_PRINTK
proc_create("kmsg", S_IRUSR, NULL, &proc_kmsg_operations);
#endif
+#ifdef CONFIG_FILE_LOCKING
proc_create("locks", 0, NULL, &proc_locks_operations);
+#endif
proc_create("devices", 0, NULL, &proc_devinfo_operations);
proc_create("cpuinfo", 0, NULL, &proc_cpuinfo_operations);
#ifdef CONFIG_BLOCK
Index: linuxdev/include/linux/fs.h
===================================================================
--- linuxdev.orig/include/linux/fs.h
+++ linuxdev/include/linux/fs.h
@@ -983,6 +983,13 @@
#include <linux/fcntl.h>
+extern void send_sigio(struct fown_struct *fown, int fd, int band);
+
+/* fs/sync.c */
+extern int do_sync_mapping_range(struct address_space *mapping, loff_t offset,
+ loff_t endbyte, unsigned int flags);
+
+#ifdef CONFIG_FILE_LOCKING
extern int fcntl_getlk(struct file *, struct flock __user *);
extern int fcntl_setlk(unsigned int, struct file *, unsigned int,
struct flock __user *);
@@ -993,14 +1000,9 @@
struct flock64 __user *);
#endif
-extern void send_sigio(struct fown_struct *fown, int fd, int band);
extern int fcntl_setlease(unsigned int fd, struct file *filp, long arg);
extern int fcntl_getlease(struct file *filp);
-/* fs/sync.c */
-extern int do_sync_mapping_range(struct address_space *mapping, loff_t offset,
- loff_t endbyte, unsigned int flags);
-
/* fs/locks.c */
extern void locks_init_lock(struct file_lock *);
extern void locks_copy_lock(struct file_lock *, struct file_lock *);
@@ -1023,6 +1025,35 @@
extern int lock_may_read(struct inode *, loff_t start, unsigned long count);
extern int lock_may_write(struct inode *, loff_t start, unsigned long count);
extern struct seq_operations locks_seq_operations;
+#else /* !CONFIG_FILE_LOCKING */
+#define fcntl_getlk(a, b) ({ -EINVAL; })
+#define fcntl_setlk(a, b, c, d) ({ -EACCES; })
+#if BITS_PER_LONG == 32
+#define fcntl_getlk64(a, b) ({ -EINVAL; })
+#define fcntl_setlk64(a, b, c, d) ({ -EACCES; })
+#endif
+#define fcntl_setlease(a, b, c) ({ 0; })
+#define fcntl_getlease(a) ({ 0; })
+#define locks_init_lock(a) ({ })
+#define __locks_copy_lock(a, b) ({ })
+#define locks_copy_lock(a, b) ({ })
+#define locks_remove_posix(a, b) ({ })
+#define locks_remove_flock(a) ({ })
+#define posix_test_lock(a, b) ({ 0; })
+#define posix_lock_file(a, b, c) ({ -ENOLCK; })
+#define posix_lock_file_wait(a, b) ({ -ENOLCK; })
+#define posix_unblock_lock(a, b) (-ENOENT)
+#define vfs_test_lock(a, b) ({ 0; })
+#define vfs_lock_file(a, b, c, d) (-ENOLCK)
+#define vfs_cancel_lock(a, b) ({ 0; })
+#define flock_lock_file_wait(a, b) ({ -ENOLCK; })
+#define __break_lease(a, b) ({ 0; })
+#define lease_get_mtime(a, b) ({ })
+#define generic_setlease(a, b, c) ({ -EINVAL; })
+#define lock_may_read(a, b, c) ({ 1; })
+#define lock_may_write(a, b, c) ({ 1; })
+#endif /* !CONFIG_FILE_LOCKING */
+
struct fasync_struct {
int magic;
@@ -1554,9 +1585,12 @@
/* /sys/fs */
extern struct kobject *fs_kobj;
+extern int rw_verify_area(int, struct file *, loff_t *, size_t);
+
#define FLOCK_VERIFY_READ 1
#define FLOCK_VERIFY_WRITE 2
+#ifdef CONFIG_FILE_LOCKING
extern int locks_mandatory_locked(struct inode *);
extern int locks_mandatory_area(int, struct inode *, struct file *, loff_t, size_t);
@@ -1587,8 +1621,6 @@
return 0;
}
-extern int rw_verify_area(int, struct file *, loff_t *, size_t);
-
static inline int locks_verify_truncate(struct inode *inode,
struct file *filp,
loff_t size)
@@ -1609,6 +1641,15 @@
return __break_lease(inode, mode);
return 0;
}
+#else /* !CONFIG_FILE_LOCKING */
+#define locks_mandatory_locked(a) ({ 0; })
+#define locks_mandatory_area(a, b, c, d, e) ({ 0; })
+#define __mandatory_lock(a) ({ 0; })
+#define mandatory_lock(a) ({ 0; })
+#define locks_verify_locked(a) ({ 0; })
+#define locks_verify_truncate(a, b, c) ({ 0; })
+#define break_lease(a, b) ({ 0; })
+#endif /* CONFIG_FILE_LOCKING */
/* fs/open.c */
Index: linuxdev/kernel/sys_ni.c
===================================================================
--- linuxdev.orig/kernel/sys_ni.c
+++ linuxdev/kernel/sys_ni.c
@@ -125,6 +125,7 @@
cond_syscall(sys_vm86);
cond_syscall(compat_sys_ipc);
cond_syscall(compat_sys_sysctl);
+cond_syscall(sys_flock);
/* arch-specific weak syscall entries */
cond_syscall(sys_pciconfig_read);
Index: linuxdev/kernel/sysctl.c
===================================================================
--- linuxdev.orig/kernel/sysctl.c
+++ linuxdev/kernel/sysctl.c
@@ -97,7 +97,7 @@
static int neg_one = -1;
#endif
-#ifdef CONFIG_MMU
+#if defined(CONFIG_MMU) && defined(CONFIG_FILE_LOCKING)
static int two = 2;
#endif
@@ -1260,6 +1260,7 @@
.extra1 = &minolduid,
.extra2 = &maxolduid,
},
+#ifdef CONFIG_FILE_LOCKING
{
.ctl_name = FS_LEASES,
.procname = "leases-enable",
@@ -1268,6 +1269,7 @@
.mode = 0644,
.proc_handler = &proc_dointvec,
},
+#endif
#ifdef CONFIG_DNOTIFY
{
.ctl_name = FS_DIR_NOTIFY,
@@ -1279,6 +1281,7 @@
},
#endif
#ifdef CONFIG_MMU
+#ifdef CONFIG_FILE_LOCKING
{
.ctl_name = FS_LEASE_TIME,
.procname = "lease-break-time",
@@ -1290,6 +1293,7 @@
.extra1 = &zero,
.extra2 = &two,
},
+#endif
{
.procname = "aio-nr",
.data = &aio_nr,
--
Thomas Petazzoni, Free Electrons
Kernel, drivers and embedded Linux development,
consulting, training and support.
http://free-electrons.com
^ permalink raw reply
* Re: embedded rootfs utility
From: Geert Uytterhoeven @ 2008-08-06 11:50 UTC (permalink / raw)
To: Behan Webster; +Cc: linux-embedded
In-Reply-To: <488FCF7D.5010005@websterwood.com>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 3131 bytes --]
Hi Behan,
On Tue, 29 Jul 2008, Behan Webster wrote:
> However, most notably it contains a utility called "elbs-rootfs" which
> makes it easy to create an embedded rootfs for any architecture
> supported by the Debian projecy (or Ubuntu Linux). The idea is to get a
> rootfs up and working quickly via nfs (or a flash drive) which allows
> you to install any debian package and/or to do native development. This
> is (not yet) meant as a tool to make your final rootfs fit on a small
> flash partition.
>
> For those of you who are interested, it does the following: builds a
> first stage debootstrap directory using a dist/mirror of your choice,
> and then tweaks it so you can boot it natively to be able to run the
> second stage debootstrap scripts. Yes, you can do all these things
> manually, however, this does it all for you in a few minutes (with
> reasonable defaults for available options). The only annoying bit is it
> must be run as root, as it needs to be able to set file
> permissions/ownerships and such.
>
> For example (as root):
>
> # elbs rootfs --arch mips --baud 19200 --dist etch /nfs/myrootfs
> I: Building rootfs in /nfs/myrootfs
> I: Installing etch/mips from http://http.us.debian.org/debian
> <snip>
> I: debootstrap succeeded
> I: MAKEDEV in /nfs/myrootfs/dev
> <snip>
> I: create /nfs/myrootfs/etc/group
> Boot your target with /nfs/myrootfs as your rootfs, then run the
> finish script on the target
>
> The directory /nfs/myrootfs will now contain a stage-one (unconfigured)
> debootstrap installation of arch mips from debian/etch, modified to
> allow you to connect to a serial console ttyS0 at 19200 baud (as
> specified on the command line above).
>
> You then need to boot your target using this rootfs and run the
> finish.sh script which will complete the installation.
>
> # sh /finish.sh
>
> You should now have a fully configured rootfs for your target which is
> capable of native compiling (amongst other things).
Thanks for this useful tool!
I'm used to plain debootstrap, but decided to give your elbs-rootfs a try for
creating up a mipsel and a powerpc NFS root file system. It worked fine,
except for one minor nit. As an NFS root file system is mounted read-only by
default, I had to manually do
| mount -n proc /proc -t proc
| mount -n -o remount -w /
before running finish.sh. Perhaps this can be added to the top of finish.sh?
Add the end of its execution, finish.sh says:
| Feel free to delete /debootstrap and the downloaded packages
| # rm -rf /debootstrap
| # apt-get clean
| Please reboot now
| # shutdown -r now
Shouldn't it suggest to delete /finish.sh, too?
Anyway, thanks for this tool!
With kind regards,
Geert Uytterhoeven
Software Architect
Sony Techsoft Centre Europe
The Corporate Village · Da Vincilaan 7-D1 · B-1935 Zaventem · Belgium
Phone: +32 (0)2 700 8453
Fax: +32 (0)2 700 8622
E-mail: Geert.Uytterhoeven@sonycom.com
Internet: http://www.sony-europe.com/
A division of Sony Europe (Belgium) N.V.
VAT BE 0413.825.160 · RPR Brussels
Fortis 293-0376800-10 GEBA-BE-BB
^ permalink raw reply
* Re: [patch 1/4] Configure out AIO support
From: Bernhard Fischer @ 2008-08-05 18:36 UTC (permalink / raw)
To: Jamie Lokier
Cc: Adrian Bunk, Thomas Petazzoni, linux-kernel, linux-embedded,
michael, Matt Mackall, bcrl, linux-aio, akpm
In-Reply-To: <20080805182607.GA28513@shareable.org>
On Tue, Aug 05, 2008 at 07:26:07PM +0100, Jamie Lokier wrote:
>> > >The userspace headers are independent of any kernel configuration
>> > >(except for the architecture).
>> >
>> > I beg to disagree:
>> > internals as exposed by e.g. aio_abi.h are impl dependent. Noone except
>> > the impl and it's users are interrested in it.
>> >...
>>
>> That's utter bullshit.
>>
>> The contents of aio_abi.h is a kernel<->userspace ABI that mustn't ever
>> change. [1]
>
>Case in point:
>
>I want to be able to compile an application for embedded Linux which
>*can use* Linux-AIO, but can also run on a kernel which has Linux-AIO
>removed by this patch.
>
>I still want to compile the application with that capability, in case
>it's run on another kernel with it enabled.
>
>I shouldn't have to have a separate, special kernel with all options
>enabled, just to compile applications that run on multiple kernels and
>use run-time features when available.
>
>Just like all the other kernel<->userspace interfaces, the header
>files (including their presence) shouldn't depend on kernel
>configuration at all.
alright, makes perfect sense. I must have been playing too much with
libc recently, i guess.
thanks,
^ permalink raw reply
* Re: [patch 1/4] Configure out AIO support
From: Jamie Lokier @ 2008-08-05 18:26 UTC (permalink / raw)
To: Adrian Bunk
Cc: Bernhard Fischer, Thomas Petazzoni, linux-kernel, linux-embedded,
michael, Matt Mackall, bcrl, linux-aio, akpm
In-Reply-To: <20080805181536.GH22895@cs181140183.pp.htv.fi>
Adrian Bunk wrote:
> On Fri, Aug 01, 2008 at 12:42:22AM +0200, Bernhard Fischer wrote:
> > On Thu, Jul 31, 2008 at 01:12:19PM +0300, Adrian Bunk wrote:
> > >On Thu, Jul 31, 2008 at 12:09:29PM +0200, Bernhard Fischer wrote:
> > >> On Thu, Jul 31, 2008 at 11:27:04AM +0200, Thomas Petazzoni wrote:
> > >> >This patchs adds the CONFIG_AIO option which allows to remove support
> > >> >for asynchronous I/O operations, that are not necessarly used by
> > >> >applications, particularly on embedded devices. As this is a
> > >> >size-reduction option, it depends on CONFIG_EMBEDDED. It allows to
> > >> >save ~7 kilobytes of kernel code/data:
> > >>
> > >> Shouldn't this also make sure not to install aio_abi.h or at least an
> > >> empty aio_abi.h?
> > >
> > >The userspace headers are independent of any kernel configuration
> > >(except for the architecture).
> >
> > I beg to disagree:
> > internals as exposed by e.g. aio_abi.h are impl dependent. Noone except
> > the impl and it's users are interrested in it.
> >...
>
> That's utter bullshit.
>
> The contents of aio_abi.h is a kernel<->userspace ABI that mustn't ever
> change. [1]
Case in point:
I want to be able to compile an application for embedded Linux which
*can use* Linux-AIO, but can also run on a kernel which has Linux-AIO
removed by this patch.
I still want to compile the application with that capability, in case
it's run on another kernel with it enabled.
I shouldn't have to have a separate, special kernel with all options
enabled, just to compile applications that run on multiple kernels and
use run-time features when available.
Just like all the other kernel<->userspace interfaces, the header
files (including their presence) shouldn't depend on kernel
configuration at all.
-- Jamie
^ permalink raw reply
* Re: [patch 1/4] Configure out AIO support
From: Adrian Bunk @ 2008-08-05 18:15 UTC (permalink / raw)
To: Bernhard Fischer
Cc: Thomas Petazzoni, linux-kernel, linux-embedded, michael,
Matt Mackall, bcrl, linux-aio, akpm
In-Reply-To: <20080731224222.GB9208@mx.loc>
On Fri, Aug 01, 2008 at 12:42:22AM +0200, Bernhard Fischer wrote:
> On Thu, Jul 31, 2008 at 01:12:19PM +0300, Adrian Bunk wrote:
> >On Thu, Jul 31, 2008 at 12:09:29PM +0200, Bernhard Fischer wrote:
> >> On Thu, Jul 31, 2008 at 11:27:04AM +0200, Thomas Petazzoni wrote:
> >> >This patchs adds the CONFIG_AIO option which allows to remove support
> >> >for asynchronous I/O operations, that are not necessarly used by
> >> >applications, particularly on embedded devices. As this is a
> >> >size-reduction option, it depends on CONFIG_EMBEDDED. It allows to
> >> >save ~7 kilobytes of kernel code/data:
> >>
> >> Shouldn't this also make sure not to install aio_abi.h or at least an
> >> empty aio_abi.h?
> >
> >The userspace headers are independent of any kernel configuration
> >(except for the architecture).
>
> I beg to disagree:
> internals as exposed by e.g. aio_abi.h are impl dependent. Noone except
> the impl and it's users are interrested in it.
>...
That's utter bullshit.
The contents of aio_abi.h is a kernel<->userspace ABI that mustn't ever
change. [1]
cu
Adrian
[1] there are some exceptions like adding stuff (but not in existing
structs), but basically the contents of aio_abi.h is cast in stone
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
^ permalink raw reply
* Re: linux under emulator
From: Grant Likely @ 2008-08-05 17:30 UTC (permalink / raw)
To: Mihaela Grigore; +Cc: linux-embedded
In-Reply-To: <78ef7ce10808051028r14aa7973t3aaa3bc92132cbba@mail.gmail.com>
On Tue, Aug 5, 2008 at 11:28 AM, Mihaela Grigore
<grigore.mihaela@gmail.com> wrote:
> If I intend to run a 2.6 linux kernel under a powerpc emulator, what
> is needed to make a minimal bootable system? I mean, apart from the
> kernel itself and busybox, do I need a bootloader ? If no actual
> hardware is used and the kernel can reside directly in ram from the
> emulator's point of view (so no relocation is needed), what else is to
> be done before the kernel can start running ?
Look at the firmware linux documentation. It should tell you
everything you need.
http://www.landley.net/code/firmware/
g.
^ permalink raw reply
* linux under emulator
From: Mihaela Grigore @ 2008-08-05 17:28 UTC (permalink / raw)
To: linux-embedded
If I intend to run a 2.6 linux kernel under a powerpc emulator, what
is needed to make a minimal bootable system? I mean, apart from the
kernel itself and busybox, do I need a bootloader ? If no actual
hardware is used and the kernel can reside directly in ram from the
emulator's point of view (so no relocation is needed), what else is to
be done before the kernel can start running ?
Thank you,
Mihaela Grigore
^ permalink raw reply
* Re: linux kernel under psim
From: Kumar Gala @ 2008-08-05 17:05 UTC (permalink / raw)
To: Mihaela Grigore; +Cc: linux-embedded
In-Reply-To: <78ef7ce10808050558j7b95f4d5vb889f167de6e44bb@mail.gmail.com>
On Aug 5, 2008, at 7:58 AM, Mihaela Grigore wrote:
> Hello,
>
> Has anyone tried or knows if it is possible to run a 2.6 linux kernel
> under psim?
not sure about psim but lots of people do it under qemu.
- k
^ permalink raw reply
* Re: Intrusion detection system
From: Kumar Gala @ 2008-08-05 13:52 UTC (permalink / raw)
To: Marco Stornelli; +Cc: Linux-Embedded
In-Reply-To: <48985582.1080001@coritel.it>
On Aug 5, 2008, at 8:28 AM, Marco Stornelli wrote:
> Kumar Gala ha scritto:
>> On Aug 5, 2008, at 3:51 AM, Marco Stornelli wrote:
>>> Hi,
>>>
>>> I have to design a network application on a board. I have to use
>>> an IDS/IPS system. Have you got any suggestions? Is there a good
>>> solution about an IDS system on embedded linux?
>> Have you looked at http://www.snort.org/?
>
> Yes I've already know it, but I compiled it and I've got a file of
> 8MB and I need even several libraries, I wondered if there was
> something more lither.
I'm not aware of anything. My understand is IDS/IPS is simple and
requires a fair amount of space.
>> I know Freescale has some embedded PPC products w/HW pattern
>> matching acceleration that are geared towards helping improving IDS/
>> IPS.
>> - k
> Can you give me some reference about it?
http://tinyurl.com/3ue6rw
http://tinyurl.com/5qg4cr
- k
^ permalink raw reply
* Re: Intrusion detection system
From: Marco Stornelli @ 2008-08-05 13:31 UTC (permalink / raw)
To: Kumar Gala; +Cc: Linux-Embedded
In-Reply-To: <48985582.1080001@coritel.it>
Marco Stornelli ha scritto:
> Kumar Gala ha scritto:
>>
>> On Aug 5, 2008, at 3:51 AM, Marco Stornelli wrote:
>>
>>> Hi,
>>>
>>> I have to design a network application on a board. I have to use an
>>> IDS/IPS system. Have you got any suggestions? Is there a good
>>> solution about an IDS system on embedded linux?
>>
>> Have you looked at http://www.snort.org/?
>
> Yes I've already know it, but I compiled it and I've got a file of 8MB
> and I need even several libraries, I wondered if there was something
> more lither.
oops, I meant more lighter.
>
>>
>> I know Freescale has some embedded PPC products w/HW pattern matching
>> acceleration that are geared towards helping improving IDS/IPS.
>>
>> - k
>>
> Can you give me some reference about it?
>
--
Marco Stornelli
Embedded Software Engineer
CoRiTeL - Consorzio di Ricerca sulle Telecomunicazioni
http://www.coritel.it
marco.stornelli@coritel.it
+39 06 72582838
^ permalink raw reply
* Re: Intrusion detection system
From: Marco Stornelli @ 2008-08-05 13:28 UTC (permalink / raw)
To: Kumar Gala; +Cc: Linux-Embedded
In-Reply-To: <5AD9E3BF-4FF2-4322-ACD5-44ABEA5B151A@kernel.crashing.org>
Kumar Gala ha scritto:
>
> On Aug 5, 2008, at 3:51 AM, Marco Stornelli wrote:
>
>> Hi,
>>
>> I have to design a network application on a board. I have to use an
>> IDS/IPS system. Have you got any suggestions? Is there a good solution
>> about an IDS system on embedded linux?
>
> Have you looked at http://www.snort.org/?
Yes I've already know it, but I compiled it and I've got a file of 8MB
and I need even several libraries, I wondered if there was something
more lither.
>
> I know Freescale has some embedded PPC products w/HW pattern matching
> acceleration that are geared towards helping improving IDS/IPS.
>
> - k
>
Can you give me some reference about it?
--
Marco Stornelli
Embedded Software Engineer
CoRiTeL - Consorzio di Ricerca sulle Telecomunicazioni
http://www.coritel.it
marco.stornelli@coritel.it
+39 06 72582838
^ permalink raw reply
* Re: Intrusion detection system
From: Kumar Gala @ 2008-08-05 13:18 UTC (permalink / raw)
To: Marco Stornelli; +Cc: Linux-Embedded
In-Reply-To: <48981481.1060701@coritel.it>
On Aug 5, 2008, at 3:51 AM, Marco Stornelli wrote:
> Hi,
>
> I have to design a network application on a board. I have to use an
> IDS/IPS system. Have you got any suggestions? Is there a good
> solution about an IDS system on embedded linux?
Have you looked at http://www.snort.org/?
I know Freescale has some embedded PPC products w/HW pattern matching
acceleration that are geared towards helping improving IDS/IPS.
- k
^ permalink raw reply
* linux kernel under psim
From: Mihaela Grigore @ 2008-08-05 12:58 UTC (permalink / raw)
To: linux-embedded
Hello,
Has anyone tried or knows if it is possible to run a 2.6 linux kernel
under psim?
ps: please add me in cc in a reply to this message.
^ permalink raw reply
* [PATCH 1/1] [x86] Configuration options to compile out x86 CPU support code
From: Thomas Petazzoni @ 2008-08-05 9:45 UTC (permalink / raw)
To: linux-kernel, linux-embedded; +Cc: Thomas Petazzoni, tglx, mingo, hpa, michael
This patch adds some configuration options that allow to compile out
CPU vendor-specific code in x86 kernels (in arch/x86/kernel/cpu). The
new configuration options are only visible when CONFIG_EMBEDDED is
selected, as they are mostly interesting for space savings reasons.
An example of size saving, on x86 with only Intel CPU support:
text data bss dec hex filename
1125479 118760 212992 1457231 163c4f vmlinux.old
1121355 116536 212992 1450883 162383 vmlinux
-4124 -2224 0 -6348 -18CC +/-
However, I'm not exactly sure that the Kconfig wording is correct with
regard to !64BIT / 64BIT.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Cc: tglx@linutronix.de
Cc: mingo@redhat.com
Cc: hpa@zytor.com
Cc: michael@free-electrons.com
---
arch/x86/Kconfig.cpu | 70 ++++++++++++++++++++++++++++++++++++++++++
arch/x86/kernel/cpu/Makefile | 19 ++++++-----
include/asm-x86/bugs.h | 5 +++
3 files changed, 85 insertions(+), 9 deletions(-)
diff --git a/arch/x86/Kconfig.cpu b/arch/x86/Kconfig.cpu
index 2c518fb..6156ac2 100644
--- a/arch/x86/Kconfig.cpu
+++ b/arch/x86/Kconfig.cpu
@@ -415,3 +415,73 @@ config X86_MINIMUM_CPU_FAMILY
config X86_DEBUGCTLMSR
def_bool y
depends on !(MK6 || MWINCHIPC6 || MWINCHIP2 || MWINCHIP3D || MCYRIXIII || M586MMX || M586TSC || M586 || M486 || M386)
+
+menuconfig PROCESSOR_SELECT
+ default y
+ bool "Supported processor vendors" if EMBEDDED
+ help
+ This lets you choose what x86 vendor support code your kernel
+ will include.
+
+config CPU_SUP_INTEL_32
+ default y
+ bool "Support Intel processors" if PROCESSOR_SELECT
+ depends on !64BIT
+ help
+ This enables extended support for Intel processors
+
+config CPU_SUP_INTEL_64
+ default y
+ bool "Support Intel processors" if PROCESSOR_SELECT
+ depends on 64BIT
+ help
+ This enables extended support for Intel processors
+
+config CPU_SUP_CYRIX_32
+ default y
+ bool "Support Cyrix processors" if PROCESSOR_SELECT
+ depends on !64BIT
+ help
+ This enables extended support for Cyrix processors
+
+config CPU_SUP_AMD_32
+ default y
+ bool "Support AMD processors" if PROCESSOR_SELECT
+ depends on !64BIT
+ help
+ This enables extended support for AMD processors
+
+config CPU_SUP_AMD_64
+ default y
+ bool "Support AMD processors" if PROCESSOR_SELECT
+ depends on 64BIT
+ help
+ This enables extended support for AMD processors
+
+config CPU_SUP_CENTAUR_32
+ default y
+ bool "Support Centaur processors" if PROCESSOR_SELECT
+ depends on !64BIT
+ help
+ This enables extended support for Centaur processors
+
+config CPU_SUP_CENTAUR_64
+ default y
+ bool "Support Centaur processors" if PROCESSOR_SELECT
+ depends on 64BIT
+ help
+ This enables extended support for Centaur processors
+
+config CPU_SUP_TRANSMETA_32
+ default y
+ bool "Support Transmeta processors" if PROCESSOR_SELECT
+ depends on !64BIT
+ help
+ This enables extended support for Transmeta processors
+
+config CPU_SUP_UMC_32
+ default y
+ bool "Support UMC processors" if PROCESSOR_SELECT
+ depends on !64BIT
+ help
+ This enables extended support for UMC processors
diff --git a/arch/x86/kernel/cpu/Makefile b/arch/x86/kernel/cpu/Makefile
index ee76eaa..a35ee92 100644
--- a/arch/x86/kernel/cpu/Makefile
+++ b/arch/x86/kernel/cpu/Makefile
@@ -7,15 +7,16 @@ obj-y += proc.o feature_names.o
obj-$(CONFIG_X86_32) += common.o bugs.o
obj-$(CONFIG_X86_64) += common_64.o bugs_64.o
-obj-$(CONFIG_X86_32) += amd.o
-obj-$(CONFIG_X86_64) += amd_64.o
-obj-$(CONFIG_X86_32) += cyrix.o
-obj-$(CONFIG_X86_32) += centaur.o
-obj-$(CONFIG_X86_64) += centaur_64.o
-obj-$(CONFIG_X86_32) += transmeta.o
-obj-$(CONFIG_X86_32) += intel.o
-obj-$(CONFIG_X86_64) += intel_64.o
-obj-$(CONFIG_X86_32) += umc.o
+
+obj-$(CONFIG_CPU_SUP_AMD_32) += amd.o
+obj-$(CONFIG_CPU_SUP_AMD_64) += amd_64.o
+obj-$(CONFIG_CPU_SUP_CYRIX_32) += cyrix.o
+obj-$(CONFIG_CPU_SUP_CENTAUR_32) += centaur.o
+obj-$(CONFIG_CPU_SUP_CENTAUR_64) += centaur_64.o
+obj-$(CONFIG_CPU_SUP_TRANSMETA_32) += transmeta.o
+obj-$(CONFIG_CPU_SUP_INTEL_32) += intel.o
+obj-$(CONFIG_CPU_SUP_INTEL_64) += intel_64.o
+obj-$(CONFIG_CPU_SUP_UMC_32) += umc.o
obj-$(CONFIG_X86_MCE) += mcheck/
obj-$(CONFIG_MTRR) += mtrr/
diff --git a/include/asm-x86/bugs.h b/include/asm-x86/bugs.h
index 021cbdd..66cf8c9 100644
--- a/include/asm-x86/bugs.h
+++ b/include/asm-x86/bugs.h
@@ -2,6 +2,11 @@
#define _ASM_X86_BUGS_H
extern void check_bugs(void);
+
+#ifdef CONFIG_CPU_SUP_INTEL_32
int ppro_with_ram_bug(void);
+#else
+#define ppro_with_ram_bug() (0)
+#endif
#endif /* _ASM_X86_BUGS_H */
--
1.5.4.3
^ permalink raw reply related
* Intrusion detection system
From: Marco Stornelli @ 2008-08-05 8:51 UTC (permalink / raw)
To: Linux-Embedded
Hi,
I have to design a network application on a board. I have to use an
IDS/IPS system. Have you got any suggestions? Is there a good solution
about an IDS system on embedded linux?
Thanks.
Regards,
--
Marco Stornelli
Embedded Software Engineer
CoRiTeL - Consorzio di Ricerca sulle Telecomunicazioni
http://www.coritel.it
marco.stornelli@coritel.it
+39 06 72582838
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox