]>
Commit | Line | Data |
---|---|---|
883fff9f KZ |
1 | 2.14: |
2 | ==== | |
f93a4afd | 3 | |
d3bb3bc8 KZ |
4 | * clean up code, gcc warnings |
5 | (try compilation with "-Wall -Wp,-D_FORTIFY_SOURCE=2") | |
3d24cec1 | 6 | |
d3bb3bc8 | 7 | * add --help and --version to all commands |
b622c840 | 8 | |
d3bb3bc8 KZ |
9 | * don't duplicate glibc code when possible, |
10 | for example things like: | |
11 | - err.h (error(), warn(), ...) | |
12 | - canonicalize_file_name() | |
13 | - program_invocation_short_name | |
883fff9f | 14 | |
d3bb3bc8 KZ |
15 | * try improve compilation against others libc: |
16 | - uClibc | |
17 | - ??? | |
18 | ||
19 | * create lib/blkdevsize.c with blkdev_get_size(), blkdev_get_sectors(), | |
20 | blkdev_get_pages() (see mkswap.c and fdisk/disksize.c) | |
21 | ||
22 | * use EXIT_FAILED and EXIT_SUCCESS | |
23 | ||
24 | * rewrite the replay script to C to avoid dependence on perl | |
25 | ||
26 | * cryptoloop support in losetup (the patch is on the way) | |
27 | ||
28 | Date: Tue, 28 Aug 2007 15:23:58 -0600 | |
29 | From: LaMont Jones <lamont@mmjgroup.com> | |
30 | Subject: Re: [PATCH] losetup: support password hashing and specifying the key length | |
31 | ||
d3bb3bc8 | 32 | * convet po/ files to UTF-8 |
f93a4afd | 33 | |
d3bb3bc8 | 34 | * use rpmatch() for all Y/N questions |
f93a4afd | 35 | |
d3bb3bc8 | 36 | * non-linux support |
b8d1314d | 37 | |
d3bb3bc8 KZ |
38 | Date: Sat, 11 Aug 2007 00:43:00 +0200 |
39 | From: Samuel Thibault <samuel.thibault@ens-lyon.org> | |
40 | Subject: non-linux support | |
883fff9f | 41 | |
d3bb3bc8 | 42 | * CFS aware chrt in util linux (the patch is on the way) |
3d24cec1 | 43 | |
d3bb3bc8 KZ |
44 | From: Christian Casteyde <casteyde.christian@free.fr> |
45 | Subject: CFS aware chrt in util linux | |
46 | Date: Sat, 21 Jul 2007 19:46:27 +0200 | |
3d24cec1 | 47 | |
d3bb3bc8 KZ |
48 | * mount: nofail mount option (the patch is on the way) |
49 | ||
50 | From: Matthias Koenig <mkoenig@suse.de> | |
51 | To: util-linux-ng@vger.kernel.org | |
52 | Subject: [PATCH] mount: nofail mount option | |
53 | ||
54 | * mount -a -- reorder fstab entries by paths before mount (just idea only) | |
55 | ||
56 | * mount -a (just idea only) | |
8b0f4ae9 | 57 | |
883fff9f KZ |
58 | Date: Sun, 3 Jun 2007 18:04:24 +0300 (MET DST) |
59 | From: Szabolcs Szakacsits <szaka@sienet.hu> | |
8b0f4ae9 | 60 | |
883fff9f KZ |
61 | In the past the right record order could be figured out easily by just |
62 | checking out fstab (if one knew what to look for) but considering the | |
63 | fastly increasing number of user space file systems and their usage, with | |
64 | their path, library, etc dependencies, it's getting trickier and is a black | |
65 | magic for most users because they simply expect drives to be mounted | |
66 | independently of their order in fstab. | |
31cc369d | 67 | |
883fff9f | 68 | One typical, wrongly edited fstab example is: |
8b0f4ae9 | 69 | |
883fff9f KZ |
70 | /dev/hda2 / ext3 defaults 1 1 |
71 | /dev/hda1 /mnt/windows ntfs-3g defaults 0 0 | |
72 | /dev/hda3 /usr ext3 defaults 0 0 | |
8b0f4ae9 | 73 | |
883fff9f | 74 | The events: |
1c51a368 | 75 | |
883fff9f KZ |
76 | mount -> /sbin/mount.ntfs-3g -> |
77 | -> resolves to <path1>/ntfs-3g via a symlink -> | |
78 | -> ntfs-3g requires at least <path2>/libfuse* | |
79 | ||
80 | There are many potential solutions. For example installing everything on | |
81 | the root file system which may be needed for successful mount. But this | |
82 | is not always feasible or practical since we could end up putting almost | |
83 | everything on the root file system in the end. | |
84 | ||
85 | Another idea is an improved mount strategy: | |
86 | ||
87 | do { | |
88 | try to mount all unmounted entries | |
89 | } while (not all mounted && at least one new was successfully mounted) | |
09dd84ca | 90 | |
d3bb3bc8 KZ |
91 | |
92 | v2.??: | |
93 | ===== | |
94 | ||
669eecf3 KZ |
95 | * rewrite ipcs to use /proc/sys/kernel rather than unreliable syscalls |
96 | (there are problems with 32bit userspace on 64bit kernel) | |
97 | ||
98 | * minix v3 | |
99 | ||
100 | From: Matthias Koenig <mkoenig@suse.de> | |
101 | Date: Tue, 25 Sep 2007 12:00:01 +0200 | |
102 | ||
103 | It seems that the kernel has support for minix fs v3 | |
104 | (though I have not tried it, just inspected some code when | |
105 | trying to find a mkfs.minix issue). | |
106 | It might be worth a thought implementing v3 support | |
107 | (though I am not really sure how much people us minix fs ;-) | |
108 | This might require some major code cleanup in mkfs.minix. | |
d3bb3bc8 | 109 |