* Re: [patch 1/4] Configure out AIO support
From: Adrian Bunk @ 2008-07-31 10:12 UTC (permalink / raw)
To: Bernhard Fischer
Cc: Thomas Petazzoni, linux-kernel, linux-embedded, michael,
Matt Mackall, bcrl, linux-aio, akpm
In-Reply-To: <20080731100929.GA9206@mx.loc>
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).
cu
Adrian
--
"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: [patch 1/4] Configure out AIO support
From: Bernhard Fischer @ 2008-07-31 10:09 UTC (permalink / raw)
To: Thomas Petazzoni
Cc: linux-kernel, linux-embedded, michael, Matt Mackall, bcrl,
linux-aio, akpm
In-Reply-To: <20080731093220.690886851@free-electrons.com>
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?
^ permalink raw reply
* Re: [patch 0/4] [resend] Add configuration options to disable features not needed on embedded devices
From: David Miller @ 2008-07-31 10:02 UTC (permalink / raw)
To: dwmw2; +Cc: torvalds, thomas.petazzoni, linux-kernel, linux-embedded, michael
In-Reply-To: <1217498355.3454.103.camel@pmac.infradead.org>
From: David Woodhouse <dwmw2@infradead.org>
Date: Thu, 31 Jul 2008 10:59:15 +0100
> I have drivers which don't even _have_ ethtool support, and they seem to
> work fine. But leaving aside the debate on that point, your statement
> also seemed to be covering the other patches, such as the IGMP one and
> others which haven't been seen (or perhaps even imagined) yet.
I explained why I didn't want to apply the IGMP one too.
Andrew didn't like my objections, but that doesn't mean I
need to defend my position further.
Show me a size reduction patch for networking that actually
makes real sense and I'll apply it.
^ permalink raw reply
* Re: [patch 0/4] [resend] Add configuration options to disable features not needed on embedded devices
From: David Woodhouse @ 2008-07-31 9:59 UTC (permalink / raw)
To: David Miller
Cc: torvalds, thomas.petazzoni, linux-kernel, linux-embedded, michael
In-Reply-To: <20080731.025547.35826309.davem@davemloft.net>
On Thu, 2008-07-31 at 02:55 -0700, David Miller wrote:
> From: David Woodhouse <dwmw2@infradead.org>
> Date: Thu, 31 Jul 2008 10:51:52 +0100
>
> > But there are a lot of people who really don't need these features
> > and really want the option of leaving them out.
>
> I'll say it one last time.
>
> If you have ipv4 enabled, you need ETHTOOL.
I have drivers which don't even _have_ ethtool support, and they seem to
work fine. But leaving aside the debate on that point, your statement
also seemed to be covering the other patches, such as the IGMP one and
others which haven't been seen (or perhaps even imagined) yet.
--
dwmw2
^ permalink raw reply
* Re: [patch 0/4] [resend] Add configuration options to disable features not needed on embedded devices
From: David Miller @ 2008-07-31 9:55 UTC (permalink / raw)
To: dwmw2; +Cc: torvalds, thomas.petazzoni, linux-kernel, linux-embedded, michael
In-Reply-To: <1217497912.3454.95.camel@pmac.infradead.org>
From: David Woodhouse <dwmw2@infradead.org>
Date: Thu, 31 Jul 2008 10:51:52 +0100
> But there are a lot of people who really don't need these features
> and really want the option of leaving them out.
I'll say it one last time.
If you have ipv4 enabled, you need ETHTOOL.
^ permalink raw reply
* Re: [patch 0/4] [resend] Add configuration options to disable features not needed on embedded devices
From: David Woodhouse @ 2008-07-31 9:51 UTC (permalink / raw)
To: David Miller, torvalds
Cc: thomas.petazzoni, linux-kernel, linux-embedded, michael
In-Reply-To: <20080731.024027.162488608.davem@davemloft.net>
On Thu, 2008-07-31 at 02:40 -0700, David Miller wrote:
> From: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
> Date: Thu, 31 Jul 2008 11:27:03 +0200
>
> > Changes since previous post:
> >
> > * Add Matt Mackall's Signed-off-by on all patches
> > * Make bonding and bridging select ethtool in the ethtool-related
> > patch.
>
> The ethtool config option needs to be selected by CONFIG_INET as well,
> as per the things I described today. Which erodes it's usefulness
> tremendously.
>
> I also am keeping my stance that I have no current intention of
> applying these patches.
I would very much like you to reconsider, Dave.
We can make them default to 'y' and hide them behind CONFIG_EMBEDDED,
and put in a scary help text that tells people _never_ to turn it off --
and hell, you can even make a taint flag for it if you like. But there
are a lot of people who really don't need these features and really want
the option of leaving them out.
Perhaps we should add a warning printk when one of these features is
'required' but absent. That would help to make it clear when someone has
disabled a feature which they shouldn't have disabled.
Refusing to apply the patches just means that either those people will
get them from elsewhere, or that their kernel will be more bloated than
it needs to be.
--
dwmw2
^ permalink raw reply
* Re: [patch 0/4] [resend] Add configuration options to disable features not needed on embedded devices
From: David Miller @ 2008-07-31 9:40 UTC (permalink / raw)
To: thomas.petazzoni; +Cc: linux-kernel, linux-embedded, michael
In-Reply-To: <20080731092703.661994657@free-electrons.com>
From: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Date: Thu, 31 Jul 2008 11:27:03 +0200
> Changes since previous post:
>
> * Add Matt Mackall's Signed-off-by on all patches
> * Make bonding and bridging select ethtool in the ethtool-related
> patch.
The ethtool config option needs to be selected by CONFIG_INET as well,
as per the things I described today. Which erodes it's usefulness
tremendously.
I also am keeping my stance that I have no current intention of
applying these patches.
^ permalink raw reply
* [patch 4/4] Configure out IGMP support
From: Thomas Petazzoni @ 2008-07-31 9:27 UTC (permalink / raw)
To: linux-kernel, linux-embedded
Cc: michael, Thomas Petazzoni, Matt Mackall, netdev, davem, akpm
In-Reply-To: <20080731092703.661994657@free-electrons.com>
[-- Attachment #1: configure-out-igmp-support --]
[-- Type: text/plain, Size: 5718 bytes --]
This patchs adds the CONFIG_IGMP option which allows to remove support
for the Internet Group Management Protocol, used in
multicast. Multicast is 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 ~10 kilobytes of
kernel code/data:
text data bss dec hex filename
1718857 143672 221184 2083713 1fcb81 vmlinux
1708838 143640 221184 2073662 1fa43e vmlinux.new
-10019 -32 0 -10051 -2743 +/-
This patch has been originally 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: netdev@vger.kernel.org
Cc: davem@davemloft.net
Cc: mpm@selenic.com
Cc: akpm@linux-foundation.org
---
include/linux/igmp.h | 20 ++++++++++++++++++++
init/Kconfig | 8 ++++++++
net/ipv4/Makefile | 3 ++-
net/ipv4/af_inet.c | 2 --
net/ipv4/ip_sockglue.c | 4 ++++
net/ipv4/sysctl_net_ipv4.c | 2 ++
6 files changed, 36 insertions(+), 3 deletions(-)
Index: linuxdev/include/linux/igmp.h
===================================================================
--- linuxdev.orig/include/linux/igmp.h
+++ linuxdev/include/linux/igmp.h
@@ -215,6 +215,7 @@
#define IGMPV3_QQIC(value) IGMPV3_EXP(0x80, 4, 3, value)
#define IGMPV3_MRC(value) IGMPV3_EXP(0x80, 4, 3, value)
+#ifdef CONFIG_IGMP
extern int ip_check_mc(struct in_device *dev, __be32 mc_addr, __be32 src_addr, u16 proto);
extern int igmp_rcv(struct sk_buff *);
extern int ip_mc_join_group(struct sock *sk, struct ip_mreqn *imr);
@@ -235,6 +236,25 @@
extern void ip_mc_dec_group(struct in_device *in_dev, __be32 addr);
extern void ip_mc_inc_group(struct in_device *in_dev, __be32 addr);
extern void ip_mc_rejoin_group(struct ip_mc_list *im);
+#else /* !CONFIG_IGMP */
+#define ip_check_mc(a, b, c, d) (0)
+#define igmp_rcv(a) (0)
+#define ip_mc_join_group(a, b) (0)
+#define ip_mc_leave_group(a, b) (0)
+#define ip_mc_drop_socket(a)
+#define ip_mc_source(a, b, c, d, e) (0)
+#define ip_mc_msfilter(a, b, c) (0)
+#define ip_mc_msfget(a, b, c, d) (0)
+#define ip_mc_gsfget(a, b, c, d) (0)
+#define ip_mc_sf_allow(a, b, c, d) (0)
+#define ip_mc_init_dev(a)
+#define ip_mc_destroy_dev(a)
+#define ip_mc_up(a)
+#define ip_mc_down(a)
+#define ip_mc_dec_group(a)
+#define ip_mc_inc_group(a)
+#define ip_mc_rejoin_group(a)
+#endif /* CONFIG_IGMP */
#endif
#endif
Index: linuxdev/init/Kconfig
===================================================================
--- linuxdev.orig/init/Kconfig
+++ linuxdev/init/Kconfig
@@ -748,6 +748,14 @@
Disabling this option removes support for configuring
ethernet device features via ethtool. Saves about 6k.
+config IGMP
+ depends on INET
+ bool "Enable IGMP support" if EMBEDDED && !IP_MULTICAST
+ default y
+ help
+ Disabling this option removes support for the Internet group
+ management protocol, used for multicast. Saves about 10k.
+
config VM_EVENT_COUNTERS
default y
bool "Enable VM event counters for /proc/vmstat" if EMBEDDED
Index: linuxdev/net/ipv4/Makefile
===================================================================
--- linuxdev.orig/net/ipv4/Makefile
+++ linuxdev/net/ipv4/Makefile
@@ -9,13 +9,14 @@
tcp.o tcp_input.o tcp_output.o tcp_timer.o tcp_ipv4.o \
tcp_minisocks.o tcp_cong.o \
datagram.o raw.o udp.o udplite.o \
- arp.o icmp.o devinet.o af_inet.o igmp.o \
+ arp.o icmp.o devinet.o af_inet.o \
fib_frontend.o fib_semantics.o \
inet_fragment.o
obj-$(CONFIG_SYSCTL) += sysctl_net_ipv4.o
obj-$(CONFIG_IP_FIB_HASH) += fib_hash.o
obj-$(CONFIG_IP_FIB_TRIE) += fib_trie.o
+obj-$(CONFIG_IGMP) += igmp.o
obj-$(CONFIG_PROC_FS) += proc.o
obj-$(CONFIG_IP_MULTIPLE_TABLES) += fib_rules.o
obj-$(CONFIG_IP_MROUTE) += ipmr.o
Index: linuxdev/net/ipv4/af_inet.c
===================================================================
--- linuxdev.orig/net/ipv4/af_inet.c
+++ linuxdev/net/ipv4/af_inet.c
@@ -115,8 +115,6 @@
#include <linux/mroute.h>
#endif
-extern void ip_mc_drop_socket(struct sock *sk);
-
/* The inetsw table contains everything that inet_create needs to
* build a new socket.
*/
Index: linuxdev/net/ipv4/ip_sockglue.c
===================================================================
--- linuxdev.orig/net/ipv4/ip_sockglue.c
+++ linuxdev/net/ipv4/ip_sockglue.c
@@ -640,6 +640,7 @@
err = ip_mc_leave_group(sk, &mreq);
break;
}
+#ifdef CONFIG_IGMP
case IP_MSFILTER:
{
extern int sysctl_igmp_max_msf;
@@ -677,6 +678,7 @@
kfree(msf);
break;
}
+#endif
case IP_BLOCK_SOURCE:
case IP_UNBLOCK_SOURCE:
case IP_ADD_SOURCE_MEMBERSHIP:
@@ -794,6 +796,7 @@
greqs.gsr_interface);
break;
}
+#ifdef CONFIG_IGMP
case MCAST_MSFILTER:
{
extern int sysctl_igmp_max_msf;
@@ -860,6 +863,7 @@
kfree(gsf);
break;
}
+#endif
case IP_ROUTER_ALERT:
err = ip_ra_control(sk, val ? 1 : 0, NULL);
break;
Index: linuxdev/net/ipv4/sysctl_net_ipv4.c
===================================================================
--- linuxdev.orig/net/ipv4/sysctl_net_ipv4.c
+++ linuxdev/net/ipv4/sysctl_net_ipv4.c
@@ -412,6 +412,7 @@
},
#endif
+#ifdef CONFIG_IGMP
{
.ctl_name = NET_IPV4_IGMP_MAX_MSF,
.procname = "igmp_max_msf",
@@ -420,6 +421,7 @@
.mode = 0644,
.proc_handler = &proc_dointvec
},
+#endif
{
.ctl_name = NET_IPV4_INET_PEER_THRESHOLD,
.procname = "inet_peer_threshold",
--
Thomas Petazzoni, Free Electrons
Kernel, drivers and embedded Linux development,
consulting, training and support.
http://free-electrons.com
^ permalink raw reply
* [patch 3/4] Configure out ethtool support
From: Thomas Petazzoni @ 2008-07-31 9:27 UTC (permalink / raw)
To: linux-kernel, linux-embedded
Cc: michael, Thomas Petazzoni, Matt Mackall, jgarzik, netdev, davem,
akpm
In-Reply-To: <20080731092703.661994657@free-electrons.com>
[-- Attachment #1: configure-out-ethtool-support --]
[-- Type: text/plain, Size: 5790 bytes --]
This patchs add the CONFIG_ETHTOOL option which allows to remove
support for ethtool, not necessarly used on embedded systems. As this
is a size-reduction option, it depends on CONFIG_EMBEDDED. It allows
to save ~6 kilobytes of kernel code:
text data bss dec hex filename
1258447 123592 212992 1595031 185697 vmlinux
1252147 123592 212992 1588731 183dfb vmlinux.new
-6300 0 0 -6300 -189C +/-
Bonding and bridging both depends on Ethtool functionnality, so
ETHTOOL is selected automatically when either bonding and bridging are
selected.
Question: should we also remove ethtool-related functions from all
network drivers ?
This patch has been originally 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: jgarzik@pobox.com
Cc: netdev@vger.kernel.org
Cc: davem@davemloft.net
Cc: mpm@selenic.com
Cc: akpm@linux-foundation.org
---
drivers/net/Kconfig | 1 +
include/linux/ethtool.h | 16 ++++++++++++++++
init/Kconfig | 8 ++++++++
net/bridge/Kconfig | 1 +
net/core/Makefile | 3 ++-
net/core/dev.c | 4 ++++
6 files changed, 32 insertions(+), 1 deletion(-)
Index: linuxdev/drivers/net/Kconfig
===================================================================
--- linuxdev.orig/drivers/net/Kconfig
+++ linuxdev/drivers/net/Kconfig
@@ -61,6 +61,7 @@
config BONDING
tristate "Bonding driver support"
depends on INET
+ select ETHTOOL
---help---
Say 'Y' or 'M' if you wish to be able to 'bond' multiple Ethernet
Channels together. This is called 'Etherchannel' by Cisco,
Index: linuxdev/include/linux/ethtool.h
===================================================================
--- linuxdev.orig/include/linux/ethtool.h
+++ linuxdev/include/linux/ethtool.h
@@ -283,6 +283,7 @@
struct net_device;
/* Some generic methods drivers may use in their ethtool_ops */
+#ifdef CONFIG_ETHTOOL
u32 ethtool_op_get_link(struct net_device *dev);
u32 ethtool_op_get_tx_csum(struct net_device *dev);
int ethtool_op_set_tx_csum(struct net_device *dev, u32 data);
@@ -296,6 +297,21 @@
int ethtool_op_set_ufo(struct net_device *dev, u32 data);
u32 ethtool_op_get_flags(struct net_device *dev);
int ethtool_op_set_flags(struct net_device *dev, u32 data);
+#else
+static inline u32 ethtool_op_get_link(struct net_device *dev) { return 0; }
+static inline u32 ethtool_op_get_tx_csum(struct net_device *dev) { return 0; }
+static inline int ethtool_op_set_tx_csum(struct net_device *dev, u32 data) { return 0; }
+static inline int ethtool_op_set_tx_hw_csum(struct net_device *dev, u32 data) { return 0; }
+static inline int ethtool_op_set_tx_ipv6_csum(struct net_device *dev, u32 data) { return 0; }
+static inline u32 ethtool_op_get_sg(struct net_device *dev) { return 0; }
+static inline int ethtool_op_set_sg(struct net_device *dev, u32 data) { return 0; }
+static inline u32 ethtool_op_get_tso(struct net_device *dev) { return 0; }
+static inline int ethtool_op_set_tso(struct net_device *dev, u32 data) { return 0; }
+static inline u32 ethtool_op_get_ufo(struct net_device *dev) { return 0; }
+static inline int ethtool_op_set_ufo(struct net_device *dev, u32 data) { return 0; }
+static inline u32 ethtool_op_get_flags(struct net_device *dev) { return 0; }
+static inline int ethtool_op_set_flags(struct net_device *dev, u32 data) { return 0; }
+#endif
/**
* ðtool_ops - Alter and report network device settings
Index: linuxdev/init/Kconfig
===================================================================
--- linuxdev.orig/init/Kconfig
+++ linuxdev/init/Kconfig
@@ -740,6 +740,14 @@
for filesystems like NFS and for the flock() system
call. Disabling this option saves about 11k.
+config ETHTOOL
+ bool "Enable ethtool support" if EMBEDDED
+ depends on NET
+ default y
+ help
+ Disabling this option removes support for configuring
+ ethernet device features via ethtool. Saves about 6k.
+
config VM_EVENT_COUNTERS
default y
bool "Enable VM event counters for /proc/vmstat" if EMBEDDED
Index: linuxdev/net/bridge/Kconfig
===================================================================
--- linuxdev.orig/net/bridge/Kconfig
+++ linuxdev/net/bridge/Kconfig
@@ -6,6 +6,7 @@
tristate "802.1d Ethernet Bridging"
select LLC
select STP
+ select ETHTOOL
---help---
If you say Y here, then your Linux box will be able to act as an
Ethernet bridge, which means that the different Ethernet segments it
Index: linuxdev/net/core/Makefile
===================================================================
--- linuxdev.orig/net/core/Makefile
+++ linuxdev/net/core/Makefile
@@ -7,10 +7,11 @@
obj-$(CONFIG_SYSCTL) += sysctl_net_core.o
-obj-y += dev.o ethtool.o dev_mcast.o dst.o netevent.o \
+obj-y += dev.o dev_mcast.o dst.o netevent.o \
neighbour.o rtnetlink.o utils.o link_watch.o filter.o
obj-$(CONFIG_XFRM) += flow.o
+obj-$(CONFIG_ETHTOOL) += ethtool.o
obj-y += net-sysfs.o
obj-$(CONFIG_NET_PKTGEN) += pktgen.o
obj-$(CONFIG_NETPOLL) += netpoll.o
Index: linuxdev/net/core/dev.c
===================================================================
--- linuxdev.orig/net/core/dev.c
+++ linuxdev/net/core/dev.c
@@ -3669,6 +3669,7 @@
return ret;
case SIOCETHTOOL:
+#ifdef CONFIG_ETHTOOL
dev_load(net, ifr.ifr_name);
rtnl_lock();
ret = dev_ethtool(net, &ifr);
@@ -3681,6 +3682,9 @@
ret = -EFAULT;
}
return ret;
+#else
+ return -EINVAL;
+#endif
/*
* These ioctl calls:
--
Thomas Petazzoni, Free Electrons
Kernel, drivers and embedded Linux development,
consulting, training and support.
http://free-electrons.com
^ permalink raw reply
* [patch 2/4] Configure out file locking features
From: Thomas Petazzoni @ 2008-07-31 9:27 UTC (permalink / raw)
To: linux-kernel, linux-embedded
Cc: michael, Thomas Petazzoni, Matt Mackall, matthew, linux-fsdevel,
akpm
In-Reply-To: <20080731092703.661994657@free-electrons.com>
[-- Attachment #1: configure-out-fs-locks-support.patch --]
[-- Type: text/plain, Size: 8797 bytes --]
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 | 2 +-
fs/Makefile | 3 ++-
fs/proc/proc_misc.c | 4 ++++
include/linux/fs.h | 52 +++++++++++++++++++++++++++++++++++++++++++++-------
init/Kconfig | 8 ++++++++
kernel/sys_ni.c | 1 +
kernel/sysctl.c | 6 +++++-
7 files changed, 66 insertions(+), 10 deletions(-)
Index: linuxdev/fs/Kconfig
===================================================================
--- linuxdev.orig/fs/Kconfig
+++ linuxdev/fs/Kconfig
@@ -1559,7 +1559,7 @@
config NFS_FS
tristate "NFS client support"
- depends on INET
+ depends on INET && FILE_LOCKING
select LOCKD
select SUNRPC
select NFS_ACL_SUPPORT if NFS_V3_ACL
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 \
seq_file.o xattr.o libfs.o fs-writeback.o \
pnode.o drop_caches.o splice.o sync.o utimes.o \
@@ -28,6 +28,7 @@
obj-$(CONFIG_TIMERFD) += timerfd.o
obj-$(CONFIG_EVENTFD) += eventfd.o
obj-$(CONFIG_AIO) += aio.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,33 @@
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_remove_posix(a, b)
+#define locks_remove_flock(a)
+#define posix_test_lock(a, b) (0)
+#define posix_lock_file(a, b) (-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 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 +1583,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 +1619,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 +1639,14 @@
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 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/init/Kconfig
===================================================================
--- linuxdev.orig/init/Kconfig
+++ linuxdev/init/Kconfig
@@ -732,6 +732,14 @@
by some high performance threaded applications. Disabling
this option saves about 7k.
+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.
+
config VM_EVENT_COUNTERS
default y
bool "Enable VM event counters for /proc/vmstat" if EMBEDDED
Index: linuxdev/kernel/sys_ni.c
===================================================================
--- linuxdev.orig/kernel/sys_ni.c
+++ linuxdev/kernel/sys_ni.c
@@ -130,6 +130,7 @@
cond_syscall(sys_io_submit);
cond_syscall(sys_io_cancel);
cond_syscall(sys_io_getevents);
+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 /* CONFIG_FILE_LOCKING */
#ifdef CONFIG_AIO
{
.procname = "aio-nr",
--
Thomas Petazzoni, Free Electrons
Kernel, drivers and embedded Linux development,
consulting, training and support.
http://free-electrons.com
^ permalink raw reply
* [patch 1/4] Configure out AIO support
From: Thomas Petazzoni @ 2008-07-31 9:27 UTC (permalink / raw)
To: linux-kernel, linux-embedded
Cc: michael, Thomas Petazzoni, Matt Mackall, bcrl, linux-aio, akpm
In-Reply-To: <20080731092703.661994657@free-electrons.com>
[-- Attachment #1: configure-out-aio-support --]
[-- Type: text/plain, Size: 4663 bytes --]
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:
text data bss dec hex filename
1115067 119180 217088 1451335 162547 vmlinux
1108025 119048 217088 1444161 160941 vmlinux.new
-7042 -132 0 -7174 -1C06 +/-
This patch has been originally 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: bcrl@kvack.org
Cc: linux-aio@kvack.org
Cc: mpm@selenic.com
Cc: akpm@linux-foundation.org
---
fs/Makefile | 3 ++-
include/linux/aio.h | 9 +++++++++
init/Kconfig | 8 ++++++++
kernel/sys_ni.c | 5 +++++
kernel/sysctl.c | 2 ++
5 files changed, 26 insertions(+), 1 deletion(-)
Index: linuxdev/fs/Makefile
===================================================================
--- linuxdev.orig/fs/Makefile
+++ linuxdev/fs/Makefile
@@ -8,7 +8,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 \
- attr.o bad_inode.o file.o filesystems.o namespace.o aio.o \
+ attr.o bad_inode.o file.o filesystems.o namespace.o \
seq_file.o xattr.o libfs.o fs-writeback.o \
pnode.o drop_caches.o splice.o sync.o utimes.o \
stack.o
@@ -27,6 +27,7 @@
obj-$(CONFIG_SIGNALFD) += signalfd.o
obj-$(CONFIG_TIMERFD) += timerfd.o
obj-$(CONFIG_EVENTFD) += eventfd.o
+obj-$(CONFIG_AIO) += aio.o
obj-$(CONFIG_COMPAT) += compat.o compat_ioctl.o
nfsd-$(CONFIG_NFSD) := nfsctl.o
Index: linuxdev/include/linux/aio.h
===================================================================
--- linuxdev.orig/include/linux/aio.h
+++ linuxdev/include/linux/aio.h
@@ -204,12 +204,21 @@
/* prototypes */
extern unsigned aio_max_size;
+#ifdef CONFIG_AIO
extern ssize_t wait_on_sync_kiocb(struct kiocb *iocb);
extern int aio_put_req(struct kiocb *iocb);
extern void kick_iocb(struct kiocb *iocb);
extern int aio_complete(struct kiocb *iocb, long res, long res2);
struct mm_struct;
extern void exit_aio(struct mm_struct *mm);
+#else
+static inline ssize_t wait_on_sync_kiocb(struct kiocb *iocb) { return 0; }
+static inline int aio_put_req(struct kiocb *iocb) { return 0; }
+static inline void kick_iocb(struct kiocb *iocb) { }
+static inline int aio_complete(struct kiocb *iocb, long res, long res2) { return 0; }
+struct mm_struct;
+static inline void exit_aio(struct mm_struct *mm) { }
+#endif /* CONFIG_AIO */
#define io_wait_to_kiocb(wait) container_of(wait, struct kiocb, ki_wait)
Index: linuxdev/init/Kconfig
===================================================================
--- linuxdev.orig/init/Kconfig
+++ linuxdev/init/Kconfig
@@ -724,6 +724,14 @@
option replaces shmem and tmpfs with the much simpler ramfs code,
which may be appropriate on small systems without swap.
+config AIO
+ bool "Enable AIO support" if EMBEDDED
+ default y
+ help
+ This option enables POSIX asynchronous I/O which may by used
+ by some high performance threaded applications. Disabling
+ this option saves about 7k.
+
config VM_EVENT_COUNTERS
default y
bool "Enable VM event counters for /proc/vmstat" if EMBEDDED
Index: linuxdev/kernel/sys_ni.c
===================================================================
--- linuxdev.orig/kernel/sys_ni.c
+++ linuxdev/kernel/sys_ni.c
@@ -125,6 +125,11 @@
cond_syscall(sys_vm86);
cond_syscall(compat_sys_ipc);
cond_syscall(compat_sys_sysctl);
+cond_syscall(sys_io_setup);
+cond_syscall(sys_io_destroy);
+cond_syscall(sys_io_submit);
+cond_syscall(sys_io_cancel);
+cond_syscall(sys_io_getevents);
/* arch-specific weak syscall entries */
cond_syscall(sys_pciconfig_read);
Index: linuxdev/kernel/sysctl.c
===================================================================
--- linuxdev.orig/kernel/sysctl.c
+++ linuxdev/kernel/sysctl.c
@@ -1290,6 +1290,7 @@
.extra1 = &zero,
.extra2 = &two,
},
+#ifdef CONFIG_AIO
{
.procname = "aio-nr",
.data = &aio_nr,
@@ -1304,6 +1305,7 @@
.mode = 0644,
.proc_handler = &proc_doulongvec_minmax,
},
+#endif /* CONFIG_AIO */
#ifdef CONFIG_INOTIFY_USER
{
.ctl_name = FS_INOTIFY,
--
Thomas Petazzoni, Free Electrons
Kernel, drivers and embedded Linux development,
consulting, training and support.
http://free-electrons.com
^ permalink raw reply
* [patch 0/4] [resend] Add configuration options to disable features not needed on embedded devices
From: Thomas Petazzoni @ 2008-07-31 9:27 UTC (permalink / raw)
To: linux-kernel, linux-embedded; +Cc: michael
Hi,
This is a resend of the small patch list I sent on July, 29th. I'm
resending the patches because they didn't make it to vger lists for
some setup problem on my side, and because I've been asked by Adrian
Bunk to resend them in order to get proper review.
However, please note that the patches removing ethtool and IGMP have
both been nack-ed by David Miller. The resend of these patches is not
an intent to workaround these NACKs in any way: I'm resending because
I've been asked to do so.
I apologize for the mess, and hope that this time, the mails will
reach vger lists.
Changes since previous post:
* Add Matt Mackall's Signed-off-by on all patches
* Make bonding and bridging select ethtool in the ethtool-related
patch.
Sincerly,
Thomas
--
Thomas Petazzoni, Free Electrons
Kernel, drivers and embedded Linux development,
consulting, training and support.
http://free-electrons.com
^ permalink raw reply
* Re: [patch 2/4] Configure out file locking features
From: Uwe Kleine-König @ 2008-07-31 6:27 UTC (permalink / raw)
To: Thomas Petazzoni
Cc: Adrian Bunk, Matthew Wilcox, linux-kernel@vger.kernel.org,
linux-embedded@vger.kernel.org, linux-fsdevel@vger.kernel.org,
mpm@selenic.com, akpm@linux-foundation.org
In-Reply-To: <20080730174028.67184ea2@surf>
Hello Thomas,
Thomas Petazzoni wrote:
> Le Wed, 30 Jul 2008 17:27:54 +0300,
> Adrian Bunk <bunk@kernel.org> a écrit :
>
> > It seems the emails containing the patches never made it to the vger
> > lists, which makes it a bit hard to comment on them.
>
> Yes, they didn't make it to the lists, for some reason. Maybe it's
> because I sent them using "quilt mail --send", which uses my local
> exim4 mail server, and for some reason, vger doesn't like that kind of
> e-mails. However, my exim4 is configured to sent the e-mails through by
> ISP SMTP. From my exim4 mainlog:
>
> 2008-07-29 17:47:57 1KNrQS-0007kt-Kg => linux-kernel@vger.kernel.org R=smarthost T=remote_smtp_smarthost H=smtp.free.fr [212.27.48.4]*
> 2008-07-29 17:47:57 1KNrQS-0007kt-Kg -> linux-embedded@vger.kernel.org R=smarthost T=remote_smtp_smarthost H=smtp.free.fr [212.27.48.4]*
> 2008-07-29 17:47:57 1KNrQS-0007kt-Kg -> netdev@vger.kernel.org R=smarthost T=remote_smtp_smarthost H=smtp.free.fr [212.27.48.4]*
> 2008-07-29 17:47:57 1KNrQS-0007kt-Kg -> davem@davemloft.net R=smarthost T=remote_smtp_smarthost H=smtp.free.fr [212.27.48.4]*
> 2008-07-29 17:47:57 1KNrQS-0007kt-Kg -> mpm@selenic.com R=smarthost T=remote_smtp_smarthost H=smtp.free.fr [212.27.48.4]*
> 2008-07-29 17:47:57 1KNrQS-0007kt-Kg -> akpm@linux-foundation.org R=smarthost T=remote_smtp_smarthost H=smtp.free.fr [212.27.48.4]*
> 2008-07-29 17:47:57 1KNrQS-0007kt-Kg -> thomas.petazzoni@free-electrons.com R=smarthost T=remote_smtp_smarthost H=smtp.free.fr [212.27.48.4]*
> 2008-07-29 17:47:57 1KNrQS-0007kt-Kg -> michael@free-electrons.com R=smarthost T=remote_smtp_smarthost H=smtp.free.fr [212.27.48.4]*
> 2008-07-29 17:47:57 1KNrQS-0007kt-Kg Completed
>
> So from my side, everything seemed to work well. Does anybody has a
> clue ?
Don't know if this is the problem, but I had problems getting mails
through some time ago, too. For me the problem was that the source
address was myusername@mymachine.intranet.$mycompany.$tld and
vger.kernel.org didn't want to take these because the host name had no
DNS entry.
I fixed that by rewriting the From line in outgoing mails on my host.
I'm using postfix (from Debian) so I had to add an entry to
/etc/postfix/sender_canonical.
Best regards
Uwe
--
Uwe Kleine-König, Software Engineer
Digi International GmbH Branch Breisach, Küferstrasse 8, 79206 Breisach, Germany
Tax: 315/5781/0242 / VAT: DE153662976 / Reg. Amtsgericht Dortmund HRB 13962
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" 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-07-30 15:40 UTC (permalink / raw)
To: Adrian Bunk
Cc: Matthew Wilcox, linux-kernel, linux-embedded, linux-fsdevel, mpm,
akpm
In-Reply-To: <20080730142754.GD19966@cs181140183.pp.htv.fi>
[-- Attachment #1: Type: text/plain, Size: 2070 bytes --]
Le Wed, 30 Jul 2008 17:27:54 +0300,
Adrian Bunk <bunk@kernel.org> a écrit :
> It seems the emails containing the patches never made it to the vger
> lists, which makes it a bit hard to comment on them.
Yes, they didn't make it to the lists, for some reason. Maybe it's
because I sent them using "quilt mail --send", which uses my local
exim4 mail server, and for some reason, vger doesn't like that kind of
e-mails. However, my exim4 is configured to sent the e-mails through by
ISP SMTP. From my exim4 mainlog:
2008-07-29 17:47:57 1KNrQS-0007kt-Kg => linux-kernel@vger.kernel.org R=smarthost T=remote_smtp_smarthost H=smtp.free.fr [212.27.48.4]*
2008-07-29 17:47:57 1KNrQS-0007kt-Kg -> linux-embedded@vger.kernel.org R=smarthost T=remote_smtp_smarthost H=smtp.free.fr [212.27.48.4]*
2008-07-29 17:47:57 1KNrQS-0007kt-Kg -> netdev@vger.kernel.org R=smarthost T=remote_smtp_smarthost H=smtp.free.fr [212.27.48.4]*
2008-07-29 17:47:57 1KNrQS-0007kt-Kg -> davem@davemloft.net R=smarthost T=remote_smtp_smarthost H=smtp.free.fr [212.27.48.4]*
2008-07-29 17:47:57 1KNrQS-0007kt-Kg -> mpm@selenic.com R=smarthost T=remote_smtp_smarthost H=smtp.free.fr [212.27.48.4]*
2008-07-29 17:47:57 1KNrQS-0007kt-Kg -> akpm@linux-foundation.org R=smarthost T=remote_smtp_smarthost H=smtp.free.fr [212.27.48.4]*
2008-07-29 17:47:57 1KNrQS-0007kt-Kg -> thomas.petazzoni@free-electrons.com R=smarthost T=remote_smtp_smarthost H=smtp.free.fr [212.27.48.4]*
2008-07-29 17:47:57 1KNrQS-0007kt-Kg -> michael@free-electrons.com R=smarthost T=remote_smtp_smarthost H=smtp.free.fr [212.27.48.4]*
2008-07-29 17:47:57 1KNrQS-0007kt-Kg Completed
So from my side, everything seemed to work well. Does anybody has a
clue ?
> Thomas, can you try to figure out what went wrong and resend them
> then?
I will send them again through my normal MUA, using quilt mail --mbox.
Hopefully it'll work.
Sincerly,
Thomas
--
Thomas Petazzoni, Free Electrons
Kernel, drivers and embedded Linux development,
consulting, training and support.
http://free-electrons.com
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: embedded rootfs utility
From: Behan Webster @ 2008-07-30 15:40 UTC (permalink / raw)
To: Marco Stornelli; +Cc: linux-embedded
In-Reply-To: <489084CB.6080305@coritel.it>
Marco Stornelli wrote:
>
> On Tue, Jul 29, 2008 at 10:18:37PM -0400, Behan Webster wrote:
>> A quick announcement of the release of elbs, or the "Embedded Linux
>> Build System" (it seemed like a good name at the time I started writing
>> it...) So far it's just a few utilities that I wrote to make a few of
>> my own projects easier.
>>
>> 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.
>>
>
> Very interesting, where can I found it? Can you give me a site to
> download it?
>
It's listed near the bottom of the announcement.
> You can find elbs at http://debian.websterwood.com/elbs/
Enjoy.
Behan
--
Behan Webster
behanw@websterwood.com
^ permalink raw reply
* Re: embedded rootfs utility
From: Marco Stornelli @ 2008-07-30 15:12 UTC (permalink / raw)
To: Behan Webster; +Cc: linux-embedded
In-Reply-To: <20080730140925.GA21958@secretlab.ca>
On Tue, Jul 29, 2008 at 10:18:37PM -0400, Behan Webster wrote:
> A quick announcement of the release of elbs, or the "Embedded Linux
> Build System" (it seemed like a good name at the time I started writing
> it...) So far it's just a few utilities that I wrote to make a few of
> my own projects easier.
>
> 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.
>
Very interesting, where can I found it? Can you give me a site to
download 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: [patch 2/4] Configure out file locking features
From: Adrian Bunk @ 2008-07-30 14:27 UTC (permalink / raw)
To: Matthew Wilcox
Cc: Thomas Petazzoni, linux-kernel, linux-embedded, linux-fsdevel,
mpm, akpm
In-Reply-To: <20080729181751.GA24924@parisc-linux.org>
It seems the emails containing the patches never made it to the vger
lists, which makes it a bit hard to comment on them.
Thomas, can you try to figure out what went wrong and resend them then?
cu
Adrian
--
"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: embedded rootfs utility
From: Grant Likely @ 2008-07-30 14:09 UTC (permalink / raw)
To: Behan Webster; +Cc: linux-embedded
In-Reply-To: <488FCF7D.5010005@websterwood.com>
On Tue, Jul 29, 2008 at 10:18:37PM -0400, Behan Webster wrote:
> A quick announcement of the release of elbs, or the "Embedded Linux
> Build System" (it seemed like a good name at the time I started writing
> it...) So far it's just a few utilities that I wrote to make a few of
> my own projects easier.
>
> 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.
Hey Behan, thanks for posting this. For anybody looking at this tool, I
can attest to it's usefulness. For my work it has simplified getting a
full development environment setup for embedded targets.
What mailing list should be used for any discussion/patches on this tool?
Cheers,
g.
^ permalink raw reply
* Re: AT91 kernel programming documentation ?
From: Robert Schwebel @ 2008-07-30 14:01 UTC (permalink / raw)
To: Stefan Schoenleitner; +Cc: linux-embedded
In-Reply-To: <4890724F.2020505@gmail.com>
On Wed, Jul 30, 2008 at 03:53:19PM +0200, Stefan Schoenleitner wrote:
> I'm looking for some good documentation concerning AT91 Linux kernel
> development. Currently I have a Olimex AT91SAM9260 development board
> which is supported by the at91 patch set.
The base functionality is supported in the Linux mainline.
> Now I would like to add different hardware to the board and write some
> kernel code for it.
What kind of hardware?
> Unfortunately, there doesn't seem to be a lot of documentation. At
> the moment I'm reading mach-at91 related source code and trying to
> find out how things work.
I assume you've already bought a copy of the Rubini Device Driver book?
> Specificly, I would like to know how the different SoC devices can be
> accessed and used, how I can do port multiplexing, how I can tell the
> kernel which hardware is attached to where and so on.
Check arch/arm/mach-at91/*. It very much depends on what you want to do.
Documentation/drivermodel/ might also be worth a look.
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
* Re: prevalence of C++ in embedded linux?
From: Bernd Petrovitsch @ 2008-07-30 13:58 UTC (permalink / raw)
To: Jamie Lokier
Cc: Bart Van Assche, Leisner, Martin, Alexander Neundorf,
linux-embedded
In-Reply-To: <20080730130712.GA12991@shareable.org>
On Wed, 2008-07-30 at 14:07 +0100, Jamie Lokier wrote:
> Bernd Petrovitsch wrote:
> > If "GOLD" is as old and flexible (and portable?) as binutils,
>
> The author says it will only work with ELF, and he does not
> intend to add support for all the other things binutils does.
Well, supporting 80% of the deployed systems requires probably only 20%
of the code;-)
But then it won't really replace binutils. And if, some quirky
hardware/systems have a problem .....
> > gcc and/or other huge software maintained to death, it is probably
> > similar complex and odd. If people take a > 10 year old tool and
> > rewrite it from scratch, I would assume that design is better.
>
> Only true if the cruft is no longer relevant. If the cruft is
> intrinsic to the problem, e.g. supporting umpteen quirky architectures
> implies umpteen quirks of cruft, then it'll be in the new design.
Yes, but one can make a better design in always knowing/planning to have
hooks here and there and everywhere.
> Btw, gcc and binutils are more like 30 years old :-)
That doesn't make it better;-)
I was too lazy to search for more exact numbers.
> > And I can't see any direct dependence on the used programming
> > language(s) if one compares running code and what is left of "design"
> > after years of design extensions, changes, enhancements, etc. to a new
> > design from scratch from the lessons learned (hopefully) from the former
> > one.
>
> Some programming languages allow you to express a problem concisely
> and clearly, and some don't. That clarity then affects whether an
And if C is too low-level, one abstracts with functions etc. I call that
"design" - independent if the design existed before the source or if the
design evolved over years with the software
And yes, at first it is enough to add a parameter and/or function here
and there without breaking implicit or explicit assumptions.
But at one point from a larger view, the "design problems" will be
obvious and one can either solve them (investing time/money for
effectively no real gain in features and/or functionality, just only
cleanups or refactoring of parts or whatever one wants to call it) or
lives on with patching/maintaining the software to death.
> evolving design becomes loaded with implementation cruft or not - and
> you can't always tell the difference.
Yes.
And over the years and decades, the implementation evolves with the
problems - new and existing ones. If the design doesn't involve - which
IMHO implies refactoring of existing, tested and working code(!)
possible breaking it - you have at some point such a mess that each
"trivial" enhancement takes age (and breaks again somewhere else
something).
> Most languages are well-matched to different problem domains.
Maybe. IMHO these differences are almost nothing compared to the below
point:
> Binutils and bfd look very crufty, but I think it's hard to tell how
> much of that is due to the implementation language and implementation,
> or the design and requirements, and how much would exist in any
> implementation on any language.
IMHO it's (mostly) independent of the implementation language:
If changes in design are not completed (including removal of old
deprecated stuff or at least push it in peripheral places where nobody
cares;-) in the implementation (for whatever reason - no one does it, no
one wants to pay it, one wants to support every API indefinitely, ....),
it will lead more sooner than later to unmaintanable crufty software.
Bernd
--
Firmix Software GmbH http://www.firmix.at/
mobil: +43 664 4416156 fax: +43 1 7890849-55
Embedded Linux Development and Services
^ permalink raw reply
* AT91 kernel programming documentation ?
From: Stefan Schoenleitner @ 2008-07-30 13:53 UTC (permalink / raw)
To: linux-embedded
Hi,
I'm looking for some good documentation concerning AT91 Linux kernel development.
Currently I have a Olimex AT91SAM9260 development board which is supported by
the at91 patch set.
Now I would like to add different hardware to the board and write some kernel
code for it.
Unfortunately, there doesn't seem to be a lot of documentation.
At the moment I'm reading mach-at91 related source code and trying to find out
how things work.
Specificly, I would like to know how the different SoC devices can be accessed
and used, how I can do port multiplexing, how I can tell the kernel which
hardware is attached to where and so on.
Can you guys suggest any documentation ?
^ permalink raw reply
* Re: prevalence of C++ in embedded linux?
From: Jamie Lokier @ 2008-07-30 13:07 UTC (permalink / raw)
To: Bernd Petrovitsch
Cc: Bart Van Assche, Leisner, Martin, Alexander Neundorf,
linux-embedded
In-Reply-To: <1217422102.7892.21.camel@spike.firmix.at>
Bernd Petrovitsch wrote:
> If "GOLD" is as old and flexible (and portable?) as binutils,
The author says it will only work with ELF, and he does not
intend to add support for all the other things binutils does.
> gcc and/or other huge software maintained to death, it is probably
> similar complex and odd. If people take a > 10 year old tool and
> rewrite it from scratch, I would assume that design is better.
Only true if the cruft is no longer relevant. If the cruft is
intrinsic to the problem, e.g. supporting umpteen quirky architectures
implies umpteen quirks of cruft, then it'll be in the new design.
Btw, gcc and binutils are more like 30 years old :-)
> And I can't see any direct dependence on the used programming
> language(s) if one compares running code and what is left of "design"
> after years of design extensions, changes, enhancements, etc. to a new
> design from scratch from the lessons learned (hopefully) from the former
> one.
Some programming languages allow you to express a problem concisely
and clearly, and some don't. That clarity then affects whether an
evolving design becomes loaded with implementation cruft or not - and
you can't always tell the difference.
Most languages are well-matched to different problem domains.
Binutils and bfd look very crufty, but I think it's hard to tell how
much of that is due to the implementation language and implementation,
or the design and requirements, and how much would exist in any
implementation on any language.
-- Jamie
^ permalink raw reply
* Re: prevalence of C++ in embedded linux?
From: Haavard Skinnemoen @ 2008-07-30 13:01 UTC (permalink / raw)
To: Jamie Lokier
Cc: Bart Van Assche, Leisner, Martin, Bernd Petrovitsch,
Alexander Neundorf, linux-embedded
In-Reply-To: <20080730123827.GA12252@shareable.org>
Jamie Lokier <jamie@shareable.org> wrote:
> The GNU Binutils requirement was to target lots of different object
> formats, and architectures, allow different ones to be interconverted
> and linked together, and to run on lots of platforms.
The Linux kernel also meets those requirements (the ones that are
relevant for a kernel that is.)
> Given those constraints, probably C was the only option at the time,
> and BFD's interface, although ugly and difficult to work with, does
> reflect the abstractions of different object formats and architectures
> moderately well IMHO.
Well, I guess it does work moderately well once you get used to it. But
there are lots of hidden dependencies all over the place. I still
haven't figured out how to un-break the debugging information after
relaxing, for example.
But what I disagree with is that these problems are somehow a symptom
of using C as the implementation language. They're a symptom of bad
design decisions IMO.
> It's tough to make a nice design that meets those requirements.
Absolutely. But does using C++ as an implementation language really
make it any easier?
> It's unfortunate that BFD is so hard to work with that people resort
> to post-processing tools and other hacks, instead of enjoying adding
> new format support to it.
>
> For all it's faults working with it, the tools themselves are very
> versatile and useful compared with most equivalents.
Agreed. I definitely prefer using the GNU tools over the alternatives
I've seen. But that doesn't mean they can't be improved further.
> If you have clear improvements that would simplify GOLD (without
> breaking it or requirements you might not be aware of), the author may
> be quite receptive to them. He seems keen on the code being of high
> quality, and he's quite experienced at working on "open" projects with
> many contributors.
Yeah, I suppose I should put my money where my mouth is and offer some
constructive suggestions. Right now I'm waiting for someone to get the
necessary paperwork in place so that we can work as closely with the
GNU community as we do with the Linux kernel and several other
communities.
Off the top of my head, after looking just at the target interface, I'd
really like to see
* A few better abstractions so that the target relocation hooks
don't need a gazillion parameters.
* Some way to spread the target implementation across a few more
files/classes so that we don't end up with a single
several-thousand-lines file for each architecture. A subdir for each
arch would be nice.
Currently, it looks like the target interface is headed down the same
road as libbfd, and that means the code will be just as unmanageable in
a few years.
I'm also curious about what things will look like once support for
complicated things like --relax and --gc-sections is added...
But I guess complaining about it here won't do much good.
Haavard
^ permalink raw reply
* Re: prevalence of C++ in embedded linux?
From: Bernd Petrovitsch @ 2008-07-30 12:48 UTC (permalink / raw)
To: Bart Van Assche
Cc: Jamie Lokier, Leisner, Martin, Alexander Neundorf, linux-embedded
In-Reply-To: <e2e108260807300404r65bfb2b2xfb07687601dc59da@mail.gmail.com>
On Wed, 2008-07-30 at 13:04 +0200, Bart Van Assche wrote:
[...]
> I don't know whether C++ is intrinsic to GOLD's linking superiority.
> The reason I cited the GOLD project is because of the programming
> style of the GOLD source code. A quote from
> http://lwn.net/Articles/274859/, about the GOLD source code:
>
> I looked through the gold sources a bit. I wish everything in the GNU
> toolchain were written this way. It is very clean code, nicely
> commented, and easy to follow. It shows pretty clearly, I think, the
> ways in which C++ can be better than C when it is used well.
If "GOLD" is as old and flexible (and portable?) as binutils, gcc and/or
other huge software maintained to death, it is probably similar complex
and odd.
If people take a > 10 year old tool and rewrite it from scratch, I would
assume that design is better.
And I can't see any direct dependence on the used programming
language(s) if one compares running code and what is left of "design"
after years of design extensions, changes, enhancements, etc. to a new
design from scratch from the lessons learned (hopefully) from the former
one.
Bernd
--
Firmix Software GmbH http://www.firmix.at/
mobil: +43 664 4416156 fax: +43 1 7890849-55
Embedded Linux Development and Services
^ permalink raw reply
* Re: prevalence of C++ in embedded linux?
From: Jamie Lokier @ 2008-07-30 12:38 UTC (permalink / raw)
To: Haavard Skinnemoen
Cc: Bart Van Assche, Leisner, Martin, Bernd Petrovitsch,
Alexander Neundorf, linux-embedded
In-Reply-To: <20080730135834.74018bf6@hskinnemo-gx745.norway.atmel.com>
Haavard Skinnemoen wrote:
> "Bart Van Assche" <bart.vanassche@gmail.com> wrote:
> > I looked through the gold sources a bit. I wish everything in the GNU
> > toolchain were written this way. It is very clean code, nicely
> > commented, and easy to follow. It shows pretty clearly, I think, the
> > ways in which C++ can be better than C when it is used well.
>
> I guess he never looked at the target interface...
>
> [snip virtual method with loads of arguments which looks like binutils]
>
> I can't wait to implement avr32 support for that monster...I thoroughly
> hate working on libbfd, and it looks like gold has made many of the
> same stupid decisions on the interface level.
> Just shows that using C++ doesn't fix a design that is broken to begin
> with.
The GNU Binutils requirement was to target lots of different object
formats, and architectures, allow different ones to be interconverted
and linked together, and to run on lots of platforms.
Given those constraints, probably C was the only option at the time,
and BFD's interface, although ugly and difficult to work with, does
reflect the abstractions of different object formats and architectures
moderately well IMHO.
It's tough to make a nice design that meets those requirements.
It's unfortunate that BFD is so hard to work with that people resort
to post-processing tools and other hacks, instead of enjoying adding
new format support to it.
For all it's faults working with it, the tools themselves are very
versatile and useful compared with most equivalents.
If you have clear improvements that would simplify GOLD (without
breaking it or requirements you might not be aware of), the author may
be quite receptive to them. He seems keen on the code being of high
quality, and he's quite experienced at working on "open" projects with
many contributors.
-- Jamie
^ 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