05 Mar, 2011
1 commit
-
This replaces all instances of lock_kernel in the
IPX code with lock_sock. As far as I can tell, this
is safe to do, because there is no global state
that needs to be locked in IPX, and the code does
not recursively take the lock or sleep indefinitely
while holding it.Compile-tested only.
Signed-off-by: Arnd Bergmann
Acked-by: David S. Miller
Cc: Arnaldo Carvalho de Melo
Cc: netdev@vger.kernel.org
21 Oct, 2010
1 commit
-
With all the patches we have queued in the BKL removal tree, only a
few dozen modules are left that actually rely on the BKL, and even
there are lots of low-hanging fruit. We need to decide what to do
about them, this patch illustrates one of the options:Every user of the BKL is marked as 'depends on BKL' in Kconfig,
and the CONFIG_BKL becomes a user-visible option. If it gets
disabled, no BKL using module can be built any more and the BKL
code itself is compiled out.The one exception is file locking, which is practically always
enabled and does a 'select BKL' instead. This effectively forces
CONFIG_BKL to be enabled until we have solved the fs/lockd
mess and can apply the patch that removes the BKL from fs/locks.c.Signed-off-by: Arnd Bergmann
01 Mar, 2007
1 commit
-
SPX was removed in early 2.5. How to connect to a Mac or the other OS isn't
hard to find out these days.Signed-off-by: Rolf Eike Beer
Signed-off-by: David S. Miller
12 Jul, 2005
1 commit
-
Move the protocol specific config options out to the specific protocols.
With this change net/Kconfig now starts to become readable and serve as a
good basis for further re-structuring.The menu structure is left almost intact, except that indention is
fixed in most cases. Most visible are the INET changes where several
"depends on INET" are replaced with a single ifdef INET / endif pair.Several new files were created to accomplish this change - they are
small but serve the purpose that config options are now distributed
out where they belongs.Signed-off-by: Sam Ravnborg
Signed-off-by: David S. Miller
17 Apr, 2005
1 commit
-
Initial git repository build. I'm not bothering with the full history,
even though we have it. We can create a separate "historical" git
archive of that later if we want to, and in the meantime it's about
3.2GB when imported into git - space that would just make the early
git days unnecessarily complicated, when we don't have a lot of good
infrastructure for it.Let it rip!
