On Tue, Jul 29, 2008 at 05:45:22PM +0200, Thomas Petazzoni wrote:
> 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
> <[email protected]>, and is part of the Linux Tiny project.
>
> Signed-off-by: Thomas Petazzoni <[email protected]>
In principle, I think this is a great idea.
> 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
I think this part is a little lazy. It should be possible to support
NFS without file locking. I suspect that's really not in-scope for the
linux-tiny tree as currently envisaged with the focus on embedded
devices that probably don't use NFS anyway. Do we want to care about
the situation of a machine with fixed workload, that doesn't need file
locking, but does use NFS?
--
Intel are signing my paycheques ... these opinions are still mine
"Bill, look, we understand that you're interested in selling us this
operating system, but compare it to ours. We can't possibly take such
a retrograde step."
On Tue, 2008-07-29 at 12:17 -0600, Matthew Wilcox wrote:
> On Tue, Jul 29, 2008 at 05:45:22PM +0200, Thomas Petazzoni wrote:
> > 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
> > <[email protected]>, and is part of the Linux Tiny project.
> >
> > Signed-off-by: Thomas Petazzoni <[email protected]>
>
> In principle, I think this is a great idea.
>
> > 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
>
> I think this part is a little lazy. It should be possible to support
> NFS without file locking. I suspect that's really not in-scope for the
> linux-tiny tree as currently envisaged with the focus on embedded
> devices that probably don't use NFS anyway. Do we want to care about
> the situation of a machine with fixed workload, that doesn't need file
> locking, but does use NFS?
I would lean towards no, but if someone comes along who cares, they're
welcome to try it. This stuff all has to strike a balance between
savings and effort/complexity/maintainability, so any time the submitter
is too lazy to cover a less common use case, it's probably a good sign
they're approaching that tipping point.
On the other hand, if you think it's trivial to do a locking-ectomy on
NFS, I'd be happy to see it.
The typical embedded NFS-based devices are NAS servers and media players
and are going to be more concerned about things like page cache
balancing.
--
Mathematics is the supreme nostalgia of our time.
Matt Mackall wrote:
> The typical embedded NFS-based devices are NAS servers and media players
> and are going to be more concerned about things like page cache
> balancing.
Oh, those.
It would be really annoying to buy a home NAS and find it doesn't
support NFS locks or SMB oplocks. NASes are vaguely useful for more
than one computer in the house at the same time.
That said, I bought a big, expensive one, found it far too slow for my
needs, send it back for a refund and bought a portable cheap USB disk
which had *so* much higher performance. The convenience of serving
multiple machines just wasn't worth the lousy performance.
-- Jamie
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
Le Wed, 30 Jul 2008 17:27:54 +0300,
Adrian Bunk <[email protected]> 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 => [email protected] R=smarthost T=remote_smtp_smarthost H=smtp.free.fr [212.27.48.4]*
2008-07-29 17:47:57 1KNrQS-0007kt-Kg -> [email protected] R=smarthost T=remote_smtp_smarthost H=smtp.free.fr [212.27.48.4]*
2008-07-29 17:47:57 1KNrQS-0007kt-Kg -> [email protected] R=smarthost T=remote_smtp_smarthost H=smtp.free.fr [212.27.48.4]*
2008-07-29 17:47:57 1KNrQS-0007kt-Kg -> [email protected] R=smarthost T=remote_smtp_smarthost H=smtp.free.fr [212.27.48.4]*
2008-07-29 17:47:57 1KNrQS-0007kt-Kg -> [email protected] R=smarthost T=remote_smtp_smarthost H=smtp.free.fr [212.27.48.4]*
2008-07-29 17:47:57 1KNrQS-0007kt-Kg -> [email protected] R=smarthost T=remote_smtp_smarthost H=smtp.free.fr [212.27.48.4]*
2008-07-29 17:47:57 1KNrQS-0007kt-Kg -> [email protected] R=smarthost T=remote_smtp_smarthost H=smtp.free.fr [212.27.48.4]*
2008-07-29 17:47:57 1KNrQS-0007kt-Kg -> [email protected] 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
Hello Thomas,
Thomas Petazzoni wrote:
> Le Wed, 30 Jul 2008 17:27:54 +0300,
> Adrian Bunk <[email protected]> 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 => [email protected] R=smarthost T=remote_smtp_smarthost H=smtp.free.fr [212.27.48.4]*
> 2008-07-29 17:47:57 1KNrQS-0007kt-Kg -> [email protected] R=smarthost T=remote_smtp_smarthost H=smtp.free.fr [212.27.48.4]*
> 2008-07-29 17:47:57 1KNrQS-0007kt-Kg -> [email protected] R=smarthost T=remote_smtp_smarthost H=smtp.free.fr [212.27.48.4]*
> 2008-07-29 17:47:57 1KNrQS-0007kt-Kg -> [email protected] R=smarthost T=remote_smtp_smarthost H=smtp.free.fr [212.27.48.4]*
> 2008-07-29 17:47:57 1KNrQS-0007kt-Kg -> [email protected] R=smarthost T=remote_smtp_smarthost H=smtp.free.fr [212.27.48.4]*
> 2008-07-29 17:47:57 1KNrQS-0007kt-Kg -> [email protected] R=smarthost T=remote_smtp_smarthost H=smtp.free.fr [212.27.48.4]*
> 2008-07-29 17:47:57 1KNrQS-0007kt-Kg -> [email protected] R=smarthost T=remote_smtp_smarthost H=smtp.free.fr [212.27.48.4]*
> 2008-07-29 17:47:57 1KNrQS-0007kt-Kg -> [email protected] 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 [email protected].$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