Displaying 20 results from an estimated 500 matches similar to: "[PATCH] getopt"
2005 Jan 05
1
[PATCH] kinit/kinit.c
A patch for a few more hiccups and trivialities in kinit.c:
* The check_path() calls check for "/root" and "/old_root" - I believe
that should be "/root" and "/root/old_root".
* chdir("/") is recommended after pivot_root()
* init_argv[0] isn't set properly to the basename pointed to by char *s
- this fix also eliminates six lines of
2005 Jan 05
1
[PATCH] kinit/nfsmount.c path from bootp
kinit/nfsmount.c:mount_nfs_root() should use the bootpath specified by
bootp/dhcp. If the "nfsroot" option is specified then it overrides the
boot server bootpath and a message indicating the override is printed.
--- klibc-0.194/kinit/nfsroot.c.orig 2005-01-05 04:13:47.043897880 -0700
+++ klibc-0.194/kinit/nfsroot.c 2005-01-05 04:13:09.316633296 -0700
@@ -66,34 +66,21 @@
const int
2004 Oct 25
1
chicken/egg between pipefs and initramfs/hotplug
I have a hotplug setup in initramfs. Everytime that modprobe is called
I get a kernel oops: NULL pointer dereference:
Unable to handle kernel NULL pointer dereference<1>Unable to handle kernel NULL pointer dereference at virtual address 00000014
printing eip:
c015db49
*pde = 00000000
Oops: 0000 [#1]
PREEMPT SMP
Modules linked in:
CPU: 3
EIP: 0060:[<c015db49>] Not tainted
2004 Oct 22
1
[PATCH] off-by-one in asprintf/vasprintf
Fix an off-by-one in asprintf and vasprintf. The return of vsnprintf is
the number of bytes *not* including the terminating '\0'. The size
argument to vsnprintf is the number of bytes *including* the terminating
'\0'.
diff -u klibc-0.188/klibc/asprintf.c udev/klibc-0.188/klibc/asprintf.c
--- klibc-0.188/klibc/asprintf.c 2004-10-22 12:07:22.678906352 -0600
+++
2005 Jan 05
1
Status/future for klibc/initramfs
I'm wondering where things are on the roadmap for klibc and
initramfs/early userspace. When will everything be harmonized with the
kernel and be the default? What is left to do?
I'm in my own little world, but I have a pretty good
klibc/hotplug/udev/kinit early userspace that just works (for me). It's
taken me a bit to get things to work because I just couldn't find all
the
2005 Jan 06
0
[PATCH] memchr and memrchr
- memchr() needs to increment pointer or it's just a busy loop (unless c
matches the first character in s)
- add memrchr.c
--- klibc-0.194/klibc/memchr.c.orig 2005-01-06 23:08:33.703355840 -0700
+++ klibc-0.194/klibc/memchr.c 2005-01-06 23:04:26.436946048 -0700
@@ -12,6 +12,7 @@
while ( n-- ) {
if ( *sp == (unsigned char)c )
return (void *)sp;
+ sp++;
}
return NULL;
2005 Jan 05
0
[PATCH] kinit/do_mounts.c:name_to_dev_t()
kinit/do_mounts.c:name_to_dev_t() has an inverted logic problem and also
doesn't return the correct value for "/dev/nfs".
--- klibc-0.194/kinit/do_mounts.c.orig 2005-01-05 01:59:29.250868616 -0700
+++ klibc-0.194/kinit/do_mounts.c 2005-01-05 02:34:30.486432256 -0700
@@ -103,7 +103,7 @@
if ( name[0] == '/' && !stat(name, &st) && S_ISBLK(st.st_mode) )
2005 Jan 05
0
[PATCH] kinit.c:get_arg()
There's an "if" statement in kinit.c:get_arg() that is too restrictive
and prevents args from having arguments - which causes all get_arg()
calls to fail:
--- klibc-0.194/kinit/kinit.c.orig 2005-01-05 01:34:50.680645456 -0700
+++ klibc-0.194/kinit/kinit.c 2005-01-05 01:38:30.740191320 -0700
@@ -168,7 +168,7 @@
for (i = 1; i < argc; i++) {
if (argv[i] &&
2005 Jan 06
0
skip unconnected interfaces
This patch makes it so that ipconfig only configures devices that are
connected:
--- klibc-0.194/ipconfig/main.c.orig 2005-01-06 15:20:24.749525888 -0700
+++ klibc-0.194/ipconfig/main.c 2005-01-06 15:24:48.038499880 -0700
@@ -27,6 +27,7 @@
static char do_not_config;
static unsigned int default_caps = CAP_DHCP | CAP_BOOTP | CAP_RARP;
static int loop_timeout = -1;
+static int only_connected = 0;
2004 Sep 16
3
[PATCH] gen_init_cpio uses external file list
(Apologies to klibc@zytor.com for the re-send)
This patch makes gen_init_cpio generate the initramfs_data.cpio from a
file which contains a list of entries: file, dir, nod. I swapped the
order of filename/location for the file arguments so that it would be
more uniform with the dir and nod tyes.
[thayne@torch linux-2.6.8]$ usr/gen_init_cpio --help
ERROR: unable to open '--help': No such
2004 Oct 25
0
[PATCH] klibc/utils/uname.c
Here's a patch to add klibc/utils/uname.c. I wrote uname.c and it can
be published under the klibc copyright/left/middle/public
domain/whatever. It supports all standard options except -p and -o.
--
Thayne Harbaugh
Linux Networx
-------------- next part --------------
A non-text attachment was scrubbed...
Name: klibc-uname.patch
Type: text/x-patch
Size: 4145 bytes
Desc: not available
Url :
2004 Oct 21
0
define more syslog flags
Define more syslog flags that are still ignored:
diff -uNr klibc-0.188/include/syslog.h udev-040/klibc-0.188/include/syslog.h
--- klibc-0.188/include/syslog.h 2003-11-23 14:46:23.000000000 -0700
+++ udev-040/klibc-0.188/include/syslog.h 2004-10-21 15:35:22.411495112 -0600
@@ -47,6 +47,14 @@
#define LOG_FACMASK 01770
#define LOG_FAC(x) (((x) >> 3) & (LOG_FACMASK
2005 Jan 06
0
[PATCH] ELF headers
This is a patch that I've had kicking around that I never sent in. With
it applied I can compile the module programs from module-init-tools:
diff -uNr klibc-0.178/include/sys/elf32.h klibc-0.178-fogo/include/sys/elf32.h
--- klibc-0.178/include/sys/elf32.h 2004-01-30 14:40:51.000000000 -0700
+++ klibc-0.178-fogo/include/sys/elf32.h 2004-09-20 09:15:58.000000000 -0600
@@ -7,6 +7,10 @@
2002 Aug 29
3
tru64 patch: openssh-SNAP-20020826.tar.gz does not contain 'configure', so how to build?
Hi-
Since the tru64 patch was designed for -current, I thought I would try
to build it with a recent snapshot before backporting to 3.4p1.
So I downloaded openssh-SNAP-20020826.tar.gz frpm the portable snapshots, but it
does not contain the 'configure' script. I tried copying the 'configure' from
3.4p1, but that does not create a Makefile from the Makefile.in.
Where are the
2002 Sep 04
2
uid transition and post-auth privsep (WAS Re: possible fundamental problem with tru64 patch) (fwd)
What do we loose by not having post-auth privsep?
What code is executed between authorization and actual setting of the
effective uid?
On Tue, 3 Sep 2002, Chris Adams wrote:
> Once upon a time, Toni L. Harbaugh-Blackford <harbaugh at nciaxp.ncifcrf.gov> said:
> > It appears that the integration of the sia session setup will either
> > have to be rethought or abandoned
2002 Sep 11
1
tru64 sia: move call of session_setup_sia() to do_setusercontext(), letting grantpty() and friends handle pty perms
Hi-
Under privsep, I experimented with moving the session_setup_sia() out of
do_child() and into do_setusercontext(), which is where the uids/gids are set
to the final execution user. The call is made with a NULL tty, and this
is functional provided that any later pty allocation uses grantpty() to
set the device permissions. Logging in with this method shows that a utmp
entry does get made for
2002 Aug 28
5
Tru64 privsep patch testing
OK, I got a chance to try out the Tru64 patch for privsep. I applied the patch
to 3.4p1. Partial success, in that it now works for me for logins to "root".
Logins to ordinary accounts fail after authentication, when trying to set tty
characteristics. See the excerpt from the debug messages below. This is for
Tru64 V4.0F (with enhanced_security turned on, obviously.) I guess it's time
2002 Aug 30
1
no, I see now, tru64 pty ownership wrong on entry to setup_sia, may need /usr/lbin/chgpt (WAS Re: Tru64 privsep patch testing)
Hi Toni,
I'm sorry, I haven't had much time to work on this today. When I run sshd
(from the patched snapshot) in a debugger, with a breakpoint early in
setup_sia(), this is what I find after connecting with a client:
(1) There are two sshd processes. One is running as root, and the other
as the user I logged with using the client. The root process is the
one in the debugger,
2002 Aug 28
1
interested tru64 unix person - privsep patch against 3.4p1 + howto /regress
Hi-
Unfortunately, I just found out about the patch that was available for
tru64 privsep. I was entirely unaware that there was a lack of support.
Will the patch be considered for approval if it is applied to 3.4p1, or does
it have to be done against -current? The reason I'm asking is that I
have 3.4p1 working as is, so I know if I have a problem it is likely
related to the patch and not
2004 Aug 19
1
tftp-hpa: getopt problems
Hi!
I hope this is the right list for sending tftpd-patches - if not, please point
me in the right direction...
I experienced quite strange problems when trying to use tftp-hpa in newer
Cygwin versions. It simply isn't able to parse its command line correctly
because it seems to use another optind variable than getopt().
When you try to start it with something like
tftpd.exe -s /mypath