yright ownership over this code then there are a
great many other people you must contact and convince first.
I would encourage you to talk privately with the Software Freedom
Conservancy before sending more patches of this nature.
Cheers,
Kyle Moffett
> diff --git a/drivers/target/target_co
one related bug-fix^Wdirty hack
for sky2 to reset the PHY a second time during netif-up after enabling
interrupts; otherwise the immediate "link up" interrupt gets lost.
Once I get approval from the company I will patch the post itself for
review.
I look forward to your comments and su
rm_policy_lock);
}
void selinux_xfrm_notify_policyload_post(void)
{
write_lock_bh(&xfrm_policy_lock);
flow_cache_ignore = 0;
write_unlock_bh(&xfrm_policy_lock);
}
Cheers,
Kyle Moffett
BEGIN QUOTED CODE INVOLVING flow_cache_genid:
include/net/flow.h:94:
extern atomic_t flow_cache_genid;
t;, possibly with
"dm-userspace" patched into the kernel to allow you to handle
non-mapped blocks in your userspace daemon when somebody tries to
access them. If you don't need that ability then straight dm-loop and
dm-linear will work.
Cheers,
Kyle Moffett
--
To unsubscribe from
frm_notify_policyload_pre(void)
{
write_lock_bh(&xfrm_policy_lock);
flow_cache_genid++;
flow_cache_ignore = 1;
write_unlock_bh(&xfrm_policy_lock);
}
void selinux_xfrm_notify_policyload_post(void)
{
write_lock_bh(&xfrm_policy_lock);
flow_cac
redundant.
For maximum readability and cleanliness I recommend that you leave off
the "extern" on the function declarations; it makes the lines much
longer without obvious gain.
Cheers,
Kyle Moffett
--
To unsubscribe from this list: send the line "unsubscribe linux-ker
er to it (and
possibly respond in kind with documentation patches).
Cheers,
Kyle Moffett
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
unt count" numbers set to primes between 7 and 37
(depending on the filesystem) so that troubled or frequently-rebooted
systems are more frequently verified. The end result is that I
almost never have the dreaded 4-hour-fsck-on-boot problem. A drive
has certainly been fscked within the
non-critical
failure; you might fail to fully sync a FUSE filesystem because its
daemon is asleep waiting on something (possibly even just sitting in
a "sleep(1)" call with all signals masked). You simply need to
make sure that all tasks are asleep outside of driver critical
ng debugged, but under Linux it's effectively impossible
Cheers,
Kyle Moffett
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
s this a good way to use sched_yield()? Maybe, maybe not. But it
*is* an actual use of the API in a real app.
We weren't looking for "actual uses", especially not in binary-only
apps. What we are looking for is optimal uses of sched_yield(); ones
where that is the best alternativ
nd use-cases for
why it cannot be implemented in user-space or with small
modifications to existing UDP/TCP networking.
Cheers,
Kyle Moffett
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
er lock (except during crash, where we break locks
already for printk()), and I doubt any of the callers would notice
the serialization since they're already serialized on the printk buffer.
Cheers,
Kyle Moffett
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel
using it in whatever fashion they desire. Typically if you price
your software reasonably people will be willing to pay for multiple
copies but there are no foolproof technical measures to enforce that
they do so.
Cheers,
Kyle Moffett
--
To unsubscribe from this list: send the line "unsub
On Nov 30, 2007, at 13:40:07, H. Peter Anvin wrote:
Kyle Moffett wrote:
With that said, there is a significant performance penalty as all
Objective-C method calls are looked up symbolically at runtime for
every single call.
GACK!
At least C++ has vtables.
In a tight loop there is a way
n the kernel though, there are many
codepaths where *every* *single* instruction counts; that could be a
serious performance hit.
Cheers,
Kyle Moffett
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majord
ed to use the appropriate commands, same as every
other VCS on the planet.
Cheers,
Kyle Moffett
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please
handler which
hooks into Xen code very precisely to create and preserve the "No
pending page table updates" state that you care about. It will be
more work in the short term but it's the only maintainable solution
in the long term IMO.
Cheers,
Kyle Moffett
-
To unsubscribe from
k first, although that
could be fixed with a few VFS and blockdev hooks which hierarchically
flush and "freeze" block devices and filesystems before actually
disabling devices much the way that device-mapper can pause a device
to take a snapshot and end up with a clean journal
On Nov 24, 2007, at 22:36:43, Crispin Cowan wrote:
Kyle Moffett wrote:
Actually, a fully-secured strict-mode SELinux system will have no
unconfined_t processes; none of my test systems have any.
Generally "unconfined_t" is used for situations similar to what
AppArmor was de
en the ability to take any action on any object by
rules in the policy, and it typically still falls under a few MLS
labeling restrictions even in the targeted policy.
Cheers,
Kyle Moffett
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a messa
r embedded architectures have very similar problems. Some may
provide an "unaligned data access" exception, but offer insufficient
information to repair the damage and resume execution.
Cheers,
Kyle Moffett
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel&quo
etwork would be expensive, but I believe the cost would
be reasonable for many applications and it would allow traditional
atomic ops on the mapped pages to take and release futexes in the
uncontended case.
Cheers,
Kyle Moffett
-
To unsubscribe from this list: send the line "unsubscribe linux
re and possibly other configuration parameters.
I'm not really that much of an expert in this particular area,
though, so it's entirely possible that one of the above-mentioned
scheduler head-honchos will poke holes in my argument and give a
better explanation or a possible patch.
C
-ASCII, change ctype.c to ignore such characters
completely (the way they were before). Linus seems to think this is
a good thing, and he's the one that wrote the code in the first place.
Signed-off-by: Kyle Moffett <[EMAIL PROTECTED]>
---
On Nov 06, 2007, at 10:53:08, Linus Tor
quot;canonical" internal text format of the kernel is
UTF-8 as that encoding can represent any character in any other
encoding and it is backwards-compatible with traditional ASCII.
Cheers,
Kyle Moffett-
To unsubscribe from this list: send the line "unsubscribe linux-kernel"
ndle basic UTF-8. (It doesn't work on special UTF-8 space
characters like nonbreaking space and similar, but handling those is
significantly more complicated).
Cheers,
Kyle Moffett
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a me
scarded, but for the bash builtin it hangs around in the buffer
for a while and ends up getting prepended to the following echo
statement. There's actually multiple ways to make this fail; this is
just the simplest.
Cheers,
Kyle Moffett
-
To unsubscribe from this list: send the line
here it did not
properly check the result of setuid() and just assumed it had
succeeded. So instead of running as "smtpd" it was running as
"root". Not a happy memory.
Cheers,
Kyle Moffett
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel"
On Oct 24, 2007, at 17:21:10, Matthew Wilcox wrote:
On Wed, Oct 24, 2007 at 04:59:48PM -0400, Kyle Moffett wrote:
This seems unlikely to work reliably as the various "v*printf"
functions modify the va_list argument they are passed. It may
happen to work on your particular ar
ably actually want to
make a copy of the varargs list for the first vsnprintf call.
Example below:
va_list argscopy;
va_copy(argscopy, args);
[...]
size = vsnprintf(s, sb->alloc - sb->len, format, argscopy)
[...]
s += sb->len - size;
vsprintf(s, format, args);
[...]
va_end(a
On Oct 12, 2007, at 01:37:23, Al Boldi wrote:
Kyle Moffett wrote:
This isn't really necessary any more with the new CFS scheduler.
If you want to prevent excess memory usage then you limit memory
usage, not process count, so just set the system max process count
to something absurdly
run an optimistically-real-time
game as one user and several thousand busy-loops as another user and
get almost picture perfect 50% CPU distribution between the users.
To me that seems a much better DoS-prevention system than limits
which don't scale based on how many people are request
On Oct 11, 2007, at 11:41:34, Casey Schaufler wrote:
--- Kyle Moffett <[EMAIL PROTECTED]> wrote:
[snipped]
I'm still waiting to see the proposed SELinux policy that does what
Smack does.
That *is* the SELinux policy which does what Smack does. I keep
having bugs in the perl
m still not seeing anything
which SELinux cannot directly implement without additional code, even
the "CAP_MAC_OVERRIDE" bit. If the semantics don't seem quite right,
please provide details about how you think the models differ and I
will try to address the concerns.
Ch
pen for up to a
year or so.
Cheers,
Kyle Moffett
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
ent bug) from what we've done
for a while. You might want to do a git-blame on this bit of code to
see who the last person to modify it was and ask them to test or
confirm the patch first. The same general questions apply to the
other logical-op bugs.
Cheers,
Kyle Moffett
-
To unsub
becomes a noticeably
invalid __attribute__((__attribute__((__pure__
Cheers,
Kyle Moffett
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
On Oct 05, 2007, at 00:45:17, Eric W. Biederman wrote:
Kyle Moffett <[EMAIL PROTECTED]> writes:
On Oct 04, 2007, at 21:44:02, Eric W. Biederman wrote:
SElinux is not all encompassing or it is generally
incomprehensible I don't know which. Or someone long ago would
have said a
in SELinux, and
efforts would be better spent in figuring out what seems too
complicated in SELinux and making it simpler. Probably a fair amount
of that just means better tools.
Cheers,
Kyle Moffett
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the
s, so let's hope gcc is actually
smart enough...
Well actually, I believe you could just do:
struct kprint_block {
const int loglevel;
[...];
};
Then cast away the constness to actually set it initially:
*((int *)&block.loglevel) = LOGLEVEL;
Cheers,
Kyle Moffett
ade useful, so perhaps it's not the
greatest idea.
I think the primary importance for this functionality is:
* Autorenaming of symlinks according to the name format string
when target or one of its ancestors is renamed or moved. This
only applies when new interface is used.
Nice.
ally always the latest Debian stable).
Cheers,
Kyle Moffett
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
th and the unlikely case is just going to burn a
bunch of CPU anyways
(B) It really is extremely unlikely that it fails (Think physical
hardware failure)
Anything else is just bogus.
Cheers,
Kyle Moffett
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
still racy against directories being moved around)
for *EVERY* directory component of *EVERY* open/chdir-ish syscall,
you are still going to be easily worked around through many different
methods.
Cheers,
Kyle Moffett
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel&
On Sep 26, 2007, at 06:27:38, David Newall wrote:
Kyle Moffett wrote:
David, please do tell myself and Adrian how "locking down" chroot
() the way you want will avoid letting root break out through any
of the above ways?
As has been said, there are thousands of ways to brea
way you have to use SELinux or capabilities, in which
case you could just take away the CAP_SYS_CHROOT capability in the
first place!
Cheers,
Kyle Moffett
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo i
s;
at least until better group-scheduling tools are produced.
Cheers,
Kyle Moffett
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
nd an initramfs into memory. Kernel is stock Debian and
hardly has enough built-in to spit at you, let alone find network/
disks, but it manages to load everything it needs off the
automagically-generated initramfs.
Cheers,
Kyle Moffett
-
To unsubscribe from this list: send the line &qu
eport where they were
called from).
Proper fix is to give __kmalloc a "void *caller" parameter and have
all of the various wrapper functions pass in the value of
__builtin_return_address() appropriately. I believe that even works
properly for inline functions which may or may not b
enumerate the various top-level allocations of IPv4 space:
http://xkcd.com/195/
Cheers,
Kyle Moffett
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-inf
On Sep 22, 2007, at 20:47:21, Joe Perches wrote:
On Sat, 2007-09-22 at 20:40 -0400, Kyle Moffett wrote:
Severity is *exactly* "desirability of logging".
Disagree.
What's info to someone is an alert to someone else. The problem is
the valuation of the reasoning.
It'
o log. I'd prefer
arbitrary control of log levels.
Umm, actually... Severity is *exactly* "desirability of logging". If
you find any place that's otherwise then please provide patches to
fix it (or at least notify the maintainer with a useful bug report
and reasoning.
C
On Sep 22, 2007, at 06:34:17, Rafael J. Wysocki wrote:
On Saturday, 22 September 2007 01:19, Kyle Moffett wrote:
On Sep 21, 2007, at 17:16:59, Jeremy Maitin-Shepard wrote:
"Rafael J. Wysocki" <[EMAIL PROTECTED]> writes:
The ACPI platform firmware is allowed to preserve infor
Very magic indeed -- Google doesn't find it, other than in your
patch. ;-)
Paul, I'm disappointed in you. That number doesn't ring a bell at
all??
(hint, ignore the 'C' that was added by me).
LOL! The RCU patent number; very clever indeed!
Cheers,
Kyle Moffett
-
able to do both, since one will be more reliable than the
other on different systems depending on what kinds of firmware bugs
they have.
Cheers,
Kyle Moffett
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PRO
On Sep 21, 2007, at 18:05:34, Joe Perches wrote:
On Fri, 2007-09-21 at 17:34 -0400, Kyle Moffett wrote:
With a bit more glue that would cause GCC to notice that for a
given qprintk_kmalloc the "qpk->type" is always zero because the
level is too high, and therefore it would opti
glue that would cause GCC to notice that for a given
qprintk_kmalloc the "qpk->type" is always zero because the level is
too high, and therefore it would optimize out *ALL* of the
_qprintk_kmalloc(), _qprintk(), and _qprintk_finish() calls.
Cheers,
Kyle Moffett
-
To u
crypto).
There is a HUGE difference between "I don't want the end-user to
hack into this" and "The end-user wants a certain degree of
assurance that his data can't be compromised.
Cheers,
Kyle Moffett
-
To unsubscribe from this list: send the line "unsubscrib
On Sep 18, 2007, at 19:44:59, Satyam Sharma wrote:
On Thu, 6 Sep 2007, Kyle Moffett wrote:
On Sep 06, 2007, at 19:35:14, Trond Myklebust wrote:
On Thu, 2007-09-06 at 19:30 -0400, Kyle Moffett wrote:
On Sep 06, 2007, at 11:06:16, J. Bruce Fields wrote:
The question of how to protect against
nsults and
flamage and I'm going to completely ignore anything further related
to atheros/licensing/etc since virtually all of the people sending
emails to the LKML can't seem to have a reasonable conversation. Plonk.
Cheers,
Kyle Moffett
-
To unsubscribe from thi
the flamefest already.
CONCLUSION:
You guys are spamming our mailing list for NO GOOD REASON Can we
*please* get back to actual useful development now?
Cheers,
Kyle Moffett
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EM
PITA for patches and logfiles.
I believe with Mail.app if you attach a .txt file it will be
unmangled and sent as "Content-Type: text/plain" and "Content-
Disposition: inline", so most email-clients will display it as part
of the message.
Cheers,
Kyle Moffett
-
To unsu
ts SIGUSR1 or
whatever from the other thread and uses that as the interrupt.
Cheers,
Kyle Moffett
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
t. Most likely there will be some major
flaw which makes it impossible to produce reliably, but the concept
contains the things I would be interested in for a real "networked
filesystem".
Cheers,
Kyle Moffett
-
To unsubscribe from this list: send the line "unsubscribe linux-ker
er, Con, and all the other major contributors
to this impressive endeavor.
Cheers,
Kyle Moffett
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-in
t with it yourself to see what the
differences are when the feature is on or off and whether or not it's
useful or harmful for your workloads. Such evidence would help
indicate which way the scheduler feature should be hard-coded when
the tunable is finally removed.
Cheers,
Kyl
fs along with the
"less" binary, so that a "vmlinuz --help" could be made to work
usefully from your bootloader.
Cheers,
Kyle Moffett
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majord
data
transferred.
Cheers,
Kyle Moffett
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
)). So far the only code
samples anybody has posted are buggy regardless of whether or not the
value and/or accessors are flagged "volatile" or not. And hey, maybe
the volatile ops *should* be implemented in inline ASM for future-
proof-ness, but that's a separate issue.
Cheers,
s-access-memory"
guarantees. If you are just interested in it as an optimization you
could probably just read the properly-aligned integer counter
directly, an atomic read on most CPUs.
If you really need it to hit main memory *every* *single* *time*
(Why? Are you using it instead of the pr
On Sep 07, 2007, at 01:14:09, Trond Myklebust wrote:
On Thu, 2007-09-06 at 20:56 -0400, Kyle Moffett wrote:
Umm, I did say "encrypt the root filesystem", didn't I? Booting
my laptops this way follows this procedure:
1) Enter BIOS boot menu
2) Insert /boot CDROM
3) Se
On Sep 06, 2007, at 19:35:14, Trond Myklebust wrote:
On Thu, 2007-09-06 at 19:30 -0400, Kyle Moffett wrote:
Actually, that's a fairly simple problem (barring disassembling
the system and attaching a hardware debugger). You encrypt the
root filesystem and require a password to boot
oader onto some read-only media (like a
finalized CDROM/DVDROM) and you're set to go.
Cheers,
Kyle Moffett
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/major
u are presently running into
and so such support was dropped by the netfilter folks. I suspect if
you CC'ed [EMAIL PROTECTED] you would get some very precise
reasons why such filtering doesn't work.
Cheers,
Kyle Moffett
-
To unsubscribe from this list: send the line "unsubscribe
s.
By using the same thread we only have one button to click to hide it
forever.
4) Refrain from rhetoric and name-calling, it's unproductive and
childish.
That said, Marc Espie seems to be all set to blast the first person
who isn't frothing at the mouth in support of BSD, s
e my
login script touch /etc/nologin and send SIGSTOP to every
The resource consumption issue is immediately over and I can go about
kicking the user and filling out all the icky paperwork.
Cheers,
Kyle Moffett
-
To unsubscribe from this list: send the line "unsubscribe linux-kerne
the stack-dump would be poking a special per-CPU value and sending
ourselves an NMI.
There are probably a half dozen other variants on ways to run
screaming to the CPU saying "It hurts mommy!" and get a new stack in
which we can play for a while.
Cheers,
Kyle Moffett
-
To unsubs
's a chance in hell
that TOMOYO will get merged as long as it has text-based-language
parsing in the kernel. You also have $NEW_RANDOM_ABUSE_OF_PROCFS and
$PATH_BASED_LSM_ISSUES. See the long flamewars on AppArmor for
discussion on the latter.
Cheers,
Kyle Moffett
-
To unsubscribe
d.
Well, you could just change the MSDOS disk label to use a different
"Partition Type" for your raid partitions. Just pick the standard
"Linux" type and you will get exactly the same behavior that
everybody who doesn't use MSDOS partition tables gets.
Cheers,
Kyle
instead of allocating
insufficient space. In the kernel it doesn't matter in practice
since you MUST have additional checking on the size of allocated
memory anyways, not even considering the fact that >PAGE_SIZE
allocations are probably going to fail with decent frequency regardles
On Aug 21, 2007, at 11:50:48, Casey Schaufler wrote:
--- Kyle Moffett <[EMAIL PROTECTED]> wrote:
Well, in this case the "box" I want to secure will eventually be
running multi-user X on a multi-level-with-IPsec network. For
that kind of protection profile, there is present
On Aug 19, 2007, at 17:12:41, [EMAIL PROTECTED] wrote:
On Sat, 18 Aug 2007 01:29:58 EDT, Kyle Moffett said:
If you can show me a security system other than SELinux which is
sufficiently flexible to secure those 2 million lines of code
along with the other 50 million lines of code found in
that people tend to kill for 1% performance
boosts, that's not likely to be a good idea.
Cheers,
Kyle Moffett
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
w me a security system other than SELinux which
is sufficiently flexible to secure those 2 million lines of code
along with the other 50 million lines of code found in various pieces
of software on my Debian box then I'll go put on my dunce hat and sit
in the corner.
Cheers,
Kyle Moffett
dir()"? Really,
none of this seems to make any sense unless you describe what is so
magical about mkdir().
I think mkdir() was just an example he was using, probably because it
was the first VFS call he needed to set a security context on. Next
would come anything which CacheFiles or N
On Aug 16, 2007, at 11:09:16, Phillip Susi wrote:
Kyle Moffett wrote:
Let me repeat myself here: Algorithmically you fundamentally
CANNOT implement inheritance-based ACLs without one of the
following (although if you have some other algorithm in mind, I'm
listening):
(A) Some ki
: somesubsys.h
I posted a comment describing a mechanism like this a couple days ago:
http://lkml.org/lkml/2007/8/14/488
Executive overview:
On Aug 15, 2007, at 07:21:04, Rafael J. Wysocki wrote:
On Wednesday, 15 August 2007 04:51, Kyle Moffett wrote:
(a) "Maintainers" files sp
Mmm, slow-as-dirt hotel wireless. What fun...
On Aug 15, 2007, at 18:14:44, Phillip Susi wrote:
Kyle Moffett wrote:
I am well aware of that, I'm simply saying that sucks. Doing a
recursive chmod or setfacl on a large directory tree is slow as
all hell.
Doing it in the kernel won
Al Viro added to the CC, since he's one of the experts on this stuff
and will probably whack me with a LART for explaining it all wrong,
or something. :-D
On Aug 15, 2007, at 16:38:36, Phillip Susi wrote:
Kyle Moffett wrote:
We've *always* had to do this; that's what "c
way you would have operated on real CVS repositories.
Just some food for thought
Cheers,
Kyle Moffett
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
to back
up your postings then please do so, but otherwise you're just wasting
time and bandwidth.
Cheers,
Kyle Moffett
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger
sensitive things like file permissions, you really do want
determinate behavior regardless of the path used to access the data.
Cheers,
Kyle Moffett
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
head. If it turns out to be better than
our existing model then I owe you a bottle of your favorite beverage.
Cheers,
Kyle Moffett
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.k
o such
matching even in polynomial time, let alone something that scales
appropriately for an OS kernel like, say, O(log(n)).
Cheers,
Kyle Moffett
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majord
(IE: file permissions) are applied. If your MAC rules are
good enough you could theoretically just chmod 6777 all the files on
the system and make them all root-owned, but why throw away mostly-
free security?
On Aug 15, 2007, at 12:36:38, Marc Perkel wrote:
--- Michael Tharp <[E
eriously doubt that anything that
far "outside the box" is going to be feasible, at least in the near
term.
Good new filesystem developments are likely to be ones which preserve
the same outer model, yet allow for deeper/more-powerful control for
those users/admins who need it.
On Aug 15, 2007, at 10:06:49, Jan Engelhardt wrote:
On Aug 15 2007 09:58, Kyle Moffett wrote:
Irrespective of whatever the standard says, EVERY platform and
compiler anybody makes nowadays has a NULL pointer value with all
bits clear. Theoretically the standard allows otherwise, but such
quot; would fail and we would start
dereferencing garbage.
Cheers,
Kyle Moffett
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
uot;user.*" extended attributes and having it save those into the git
repo along with the permission data.
Cheers,
Kyle Moffett
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http:
1 - 100 of 360 matches
Mail list logo