the
> >
> > task which shared same CPU core.
> >
>
> Hmm, it seems you just make the sort slower, and nothing more changes.
> Am I right ?
Well, it has to make the sort slower, but it'll also avoid hogging the
CPU (on a non-preemptible kernel), avoiding a potential soft lockup
warning and allowing other tasks to run.
--
Vojtech Pavlik
VP SUSE Labs
ases in a
time window after that.
> Let me gain some experience with the patch. I don't think hardware
> does as heavy debouncing as you describe.
Microswitches vibrate significantly when clicked. Without hardware
debouncing, you'd have many clicks instead of one even on a new mouse.
--
Vojtech Pavlik
PS/2) between updates from the hardware, a
real doubleclick can look absolutely the same as what you observe as a
bounce.
As such, it couldn't be enabled by default.
If you really want to go this way, a userspace solution is the better choice.
--
Vojtech Pavlik
Force RS */
> { USB_DEVICE(0x061c, 0xc084) }, /* ACT LABS Force RS */
> + { USB_DEVICE(0x06a3, 0xff04) }, /* Saitek R440 Force Wheel */
> { USB_DEVICE(0x06f8, 0x0001) }, /* Guillemot Race Leader Force
> Feedback */
> { USB_DEVICE(0x06f8, 0x0003) }, /* Guillemot Jet Leader Force
> Feedback */
> { USB_DEVICE(0x06f8, 0x0004) }, /* Guillemot Force Feedback
> Racing Wheel */
> --
> 2.19.1.450.ga4b8ab536
>
--
Vojtech Pavlik
Director SUSE Labs
this way, but nevertheless, the
address isn't valid anymore, so removing it makes good sense.
--
Vojtech Pavlik
Director SUSE Labs
rved space, so I can have caching _and_ compatibility with
> grub2 etc (and avoid 400GB move):
The common way to do that is to move the beginning of the partition,
assuming your ext4 lives in a partition.
I don't see how overlapping the ext4 and the bcache backing device
starts would give you what you want, because bcache assumes the
backing device data starts with an offset.
--
Vojtech Pavlik
nwinder against
each kernel code address verifying the output and bail if there is a bug
in the toolchain that affects it.
--
Vojtech Pavlik
Director SuSE Labs
gameport_driver *drv)
>
> gf2k_trigger_seq(gameport, gf2k_seq_reset);
>
> - msleep(GF2K_TIMEOUT);
> + usleep_range(GF2K_TIMEOUT, GF2K_TIMEOUT + 100);
>
> gf2k_trigger_seq(gameport, gf2k_seq_digital);
>
> - msleep(GF2K_TIMEOUT);
> + usleep_range(GF2K_TIMEOUT, GF2K_TIMEOUT + 100);
>
> if (gf2k_read_packet(gameport, GF2K_LENGTH, data) < 12) {
> err = -ENODEV;
> --
> 2.6.2
>
--
Vojtech Pavlik
+ 100);
> + t = gameport_time(gameport, ANALOG_MAX_TIME);
> gameport_trigger(gameport);
> while ((gameport_read(port->gameport) & port->mask) && (u < t))
> u++;
> --
> 2.6.2
>
--
Vojtech Pavlik
gt; goto fail2;
> }
> - msleep(SW_TIMEOUT);
> + usleep_range(SW_TIMEOUT, SW_TIMEOUT + 100);
> j = sw_read_packet(gameport, idbuf, SW_LENGTH, i); /*
> Retry reading ID */
> dbg("Init 2c: ID Length %d.", j);
> }
> @@ -655,7 +655,7 @@ static int sw_connect(struct gameport *gameport, struct
> gameport_driver *drv)
>
> do {
> k--;
> - msleep(SW_TIMEOUT);
> + usleep_range(SW_TIMEOUT, SW_TIMEOUT + 100);
> i = sw_read_packet(gameport, buf, SW_LENGTH, 0);/* Read
> data packet */
> dbg("Init 3: Mode %d. Length %d. Last %d. Tries %d.", m, i, l,
> k);
>
> --
> 2.6.2
>
--
Vojtech Pavlik
On Mon, Apr 04, 2016 at 01:33:07PM -0500, Josh Poimboeuf wrote:
> On Mon, Apr 04, 2016 at 08:27:59PM +0200, Vojtech Pavlik wrote:
> > On Mon, Apr 04, 2016 at 01:21:38PM -0500, Josh Poimboeuf wrote:
> >
> > > Hm, can you explain why it should be copied from the parent?
&
does that sound?
How could a newly forked task start in the old universe if its parent
has already been migrated? Any context it inherits will already be from
the new universe.
--
Vojtech Pavlik
Director SuSE Labs
> M: Josh Poimboeuf
> -M: Seth Jennings
> +M: Jessica Yu
> M: Jiri Kosina
> -M: Vojtech Pavlik
> +M: Miroslav Benes
> +R: Petr Mladek
> S: Maintained
> F: kernel/livepatch/
> F: include/linux/livepatch.h
> --
> 2.4.3
Acked-by: Vojtech Pavlik
--
Vojtech Pavlik
Director SuSE Labs
Fix writeback_thread never finishing writing back all dirty data in bcache when
partial_stripes_expensive is set, and spinning, consuming 100% of CPU instead.
Signed-off-by: Vojtech Pavlik
---
This is a fix for the current upstream bcache, not the devel branch.
If partial_stripes_expensive is
Each callable function must never leave its own bounds (i.e. with a
> >jump to outside the function) except when returning.
>
> Won't that break with sibling/tail calls? GCC can generate those, and
> the ia32_ptregs_common label is an example of such a thing.
It only validate
he device and or driver. How ugly would
> they be?
A windows translation layer is fairly easy, people porting software from
Windows to Linux told me numerous times that adapting isn't hard. I also
believe that at least one of the BSD's has a compatible implementation
these days based on
r _how_ to do. Particularly with Linux kernel's
development model where internal ABI and structures are always in flux
it may not even be realistic.
> Granted, with live kernel upgrades it's much more complex
> to get the 'simple' case into an even rudimentarily working
&g
#x27;d only do it only in special cases, where for some
> reason the initialization sequence takes longer time and it
> makes sense to share hardware discovery information between
> two versions of the driver. I'm not convinced such a
> mechanism is necessary in the general c
ngle
> attribute.
It's an attribute I'm not willing to give up. On the other hand, I
definitely wouldn't argue against having modes of operation where the
latency is higher and the tool is more powerful.
> I.e. don't make it a single-issue project.
There is no need to wor
has tools to automate the generation of patches,
these are generally not required to create a patch.
--
Vojtech Pavlik
Director SUSE Labs
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at ht
conds of outage may be acceptable in a disaster scenario. Not
necessarily for a regular update scenario.
The value of live patching is in near zero disruption.
--
Vojtech Pavlik
Director SUSE Labs
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a
"LEAVE_KERNEL+SWITCH_KERNEL" model. It's indeed the strongest model of
all, but also comes at the highest cost in terms of impact on running
tasks. It's so high (the interruption may be seconds or more) that it
was deemed not worth implementing.
--
Vojtech Pavlik
Director SUSE
On Thu, Feb 19, 2015 at 11:32:55AM -0600, Josh Poimboeuf wrote:
> On Thu, Feb 19, 2015 at 06:19:29PM +0100, Vojtech Pavlik wrote:
> > On Thu, Feb 19, 2015 at 11:03:53AM -0600, Josh Poimboeuf wrote:
> > > On Thu, Feb 19, 2015 at 05:33:59PM +0100, Vojtech Pavlik wrote:
> >
TIF_IN_USERSPACE))
> klp_switch_task_universe(task);
The s390x arch used to have a TIF_SYSCALL, which was doing exactly that (well,
negated). I think it would work well, but it isn't entirely for free: two
instructions per syscall and an extra TIF bit, which are (near) exhausted on
On Thu, Feb 19, 2015 at 11:03:53AM -0600, Josh Poimboeuf wrote:
> On Thu, Feb 19, 2015 at 05:33:59PM +0100, Vojtech Pavlik wrote:
> > On Thu, Feb 19, 2015 at 10:24:29AM -0600, Josh Poimboeuf wrote:
> >
> > > > No, these tasks will _never_ make syscalls. So you need to g
t; > > Patching thread_fn wouldn't be possible unless we killed the thread.
> >
> > It is, see kthread_park().
>
> When the kthread returns from kthread_parkme(), it'll still be running
> the old thread_fn code, regardless of whether we flipped the task's
On Thu, Feb 19, 2015 at 10:52:51AM +0100, Peter Zijlstra wrote:
> On Wed, Feb 18, 2015 at 09:44:44PM +0100, Vojtech Pavlik wrote:
> > For live patching it doesn't matter whether code is running, sleeping or
> > frozen.
> >
> > What matters is whether there is st
rnel threads.
It isn't a given property of the freezer itself, though. And isn't
obvious for author of new kernel threads either.
The ideal solution would be to convert the majority of kernel threads to
workqueues, because then there is a defined entry/exit point over which
state isn't
e equal, others can comment
Since any loaded kernel module can do virtually anything on a machine,
there can only be one level of trust. As such, all trusted keys are
equally trusted.
--
Vojtech Pavlik
Director SUSE Labs
--
To unsubscribe from this list: send the line "unsubscribe linux-ke
many considerations) and whether one
is enough, or whether an engine that can do more than one is required.
The consistency models of kpatch and kGraft aren't directly compatible.
I think we're on a good way towards a single model, but we'll see when
it's implemented within th
the patch changes, then it cannot be
applied.
If the changes are small and localized, don't depend on the order in
which individual functions are replaced, when both new and old code can
run in parallel on different CPUs or in sequence in a single thread
safely, then it can be applied.
--
Vo
o choose the "switch-timing" based on the patch's consistency
> requirement.
That's what I'm thinking about, too. But I'm also thinking, "this will
be complex, is it really needed"?
> Anyway, I'd like to support for this effort from kernel side.
switch per-thread like
kGraft does, not for the whole system, when the respective counters
reach zero.
This handles the frequent sleeper case, it doesn't need annotated kernel
thread main loops, it will not need the user to wake up every process in
the system unless it sleeps in a
or SIGSTOP/SIGCONT. It's one of the disadvantages
of kGraft that sleeper threads have to be handled possibly case by case.
Also, kernel threads are problematic for kGraft (as you may have seen in
earlier kGraft upstream submissions) as they never leave the kernel.
--
Vojtech Pavlik
Director SUSE Labs
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
#x27;re trying to patch a
> function which is always active. Agreed :-)
Yes.
> > With LEAVE_PATCHED_SET SWITCH_KERNEL, you have to find the perfect
> > moment when all of the threads are outside of the patched set at the
> > same time. Depending on how often the functions are us
On Fri, Nov 07, 2014 at 09:45:53PM -0600, Josh Poimboeuf wrote:
> On Fri, Nov 07, 2014 at 10:27:35PM +0100, Vojtech Pavlik wrote:
> > On Fri, Nov 07, 2014 at 09:45:00AM -0600, Josh Poimboeuf wrote:
> >
> > > > LEAVE_FUNCTION
> > > > LEAVE_P
d way would be to go with SWITCH_THREAD for the simpler stuff
and do a SWITCH_KERNEL for the 10% of complex patches. This because
(LEAVE_PATCHED_SET) SWITCH_THREAD finishes much quicker. But I'm biased
there. ;)
It seems more and more to me that we will actually want the more
powerful engine coping with the various options.
--
Vojtech Pavlik
Director SUSE Labs
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
om,
thanks to ftrace, into what the consistency model should look like.
PPS.: I haven't included any handling of changed data structures in
this, that's another set of properties.
--
Vojtech Pavlik
Director SUSE Labs
--
To unsubscribe from this list: send the line "unsubscribe li
On Fri, Nov 07, 2014 at 06:31:54AM -0600, Josh Poimboeuf wrote:
> On Thu, Nov 06, 2014 at 09:24:23PM +0100, Vojtech Pavlik wrote:
> > On Thu, Nov 06, 2014 at 10:58:57AM -0800, Christoph Hellwig wrote:
> >
> > > On Thu, Nov 06, 2014 at 07:51:57PM +0100, Vojtech Pavlik wrot
On Thu, Nov 06, 2014 at 10:58:57AM -0800, Christoph Hellwig wrote:
> On Thu, Nov 06, 2014 at 07:51:57PM +0100, Vojtech Pavlik wrote:
> > I don't think this specific example was generated.
> >
> > I also don't think including the whole kpatch automation into
is a viable development model for it. (Same would apply for kGraft
automation.)
So I believe including one or more human produced examples makes most sense.
--
Vojtech Pavlik
Director SUSE Labs
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body
unexported symbols if any are
referenced.
So no objection to the idea. We'll have to look more into the code to
comment on the implementation of the dynrela stuff.
--
Vojtech Pavlik
Director SUSE Labs
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel&qu
any kind
of consistency when patching, so TIF_KGR and the lazy migration will not
exist, and neither will we be stopping the kernel or checking stacks.
This will make applying patches bigger than a single functions tricky,
but it's a good initial goal.
--
Vojtech Pavlik
Director SU
Hello Heiko,
I can confirm that kGraft works well on top of current mainline with
this patch added.
Another reason for a performance impact when kGraft is enabled is that
kGraft still adds two instructions to the syscall path on s390x, as
there is no space left for a kgraft TIF in the first eight
d_read() reliable even when the speed of the i/o operations
changes.
What is important is that the GET_TIME() macro is fast (0.1 usec or
less), precise (sub-microsecond resolution) and reliable. Digital
protocols also rely on udelay() and mdelay() waiting precisely for the
amount of time specified.
ort-adapter-reviews/reviews.htm
> >
>
> They have better chance of being supported ;) I had a couple a few years back
> and they did work for me.
They do work for analog joysticks if you don't want any extended
functionality. I have a couple in said box.
--
Vojtech Pavlik
Dir
on of return address by changing the PSW (instruction
pointer) member od struct pt_regs.
Signed-off-by: Vojtech Pavlik
Reviewed-by: Jiri Kosina
Cc: Steven Rostedt
---
arch/s390/Kconfig |1
arch/s390/include/asm/ftrace.h |4 ++
arch/s390/include/asm/lowcore.h |
esn't add any overhead if kGraft is not
> enabled. What other hot paths do you refer to?
As Jiří says, I don't see any hot path where kGraft would add
instructions: Kernel exit and entry are handled outside the hot path
in the _TIF_WORK_SYSCALL_ENTRY and _TIF_ALLWORK_MASK handlers. [patch 1
ress on stack
* Second NMI handler ends
* First NMI handler ends and goes into an infinite IRET loop, always
returning to the beginning of itself
But you do have all the ingredients.
And I don't see any other way out than not calling IRET for MCEs.
--
Vojtech Pavli
ppen.
>
> And I guess similar thing may happen with kgraft. If old function and
> new function share a non-auto variable and they modify it different way,
> the result will be unexpected by the mutual interference.
By non-auto I assume you mean globally accessible variable or data
structures.
nd try_to_freeze() and kgr_task_safe() nicely
into one place and at the same time put enough constraint on what the
thread function can do to prevent it from breaking the assumptions of
each of these calls.
--
Vojtech Pavlik
SUSE Labs
--
To unsubscribe from this list: send the line &
ty only in the
space between the NMI handler start and the check), a SMI-triggered
nested NMI has happened.
Then we should be able to at least report it before dying.
If it doesn't ever happen: Great, this wasn't a real concern. If it
does, we can pester BIOS vendors.
--
Vojtech Pavl
On Wed, Apr 30, 2014 at 09:55:32AM -0700, Paul E. McKenney wrote:
> On Wed, Apr 30, 2014 at 04:30:42PM +0200, Jiri Slaby wrote:
> > Some threads do not use kthread_should_stop. Before we enable a
> > kthread support in kgr, we must make sure all those mark themselves
> > safe explicitly.
>
> Would
as threatened.
This I'm offering my time, my helping hand and my thoughts to the TAB,
hoping that I can contribute to solving any future problems Linux and
the Linux Foundation may face.
Vojtech Pavlik
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel"
than the next kernel can do the
> > validation since the validating key has to be secret
>
> This is true, but as you said, the relevance of this seems to be rather
> questionable.
Indeed, it's hard to imagine a scenario that is also valid within the
secure boot threat mod
rcise is to minimize the number of writes to
> the NVRAM. The hash changes with every hibernation, obviously.
The key should, too.
--
Vojtech Pavlik
Director SUSE Labs
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@v
much more complicated, and it gives you all
these benefits even with secure boot disabled.
--
Vojtech Pavlik
Director SUSE Labs
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
d Mr Evil Blackhat would have
> to find a new bunch of identity documents to create a new account to
> repeat the process.
Yes, from the point it gets blacklisted, it's fairly clear. You're
forced to reboot, but under the Secure Boot model, you have to do that
on any system that used cod
GA code changes with different keyboards attached?
> Best regards,
>
> Javier
>
> Vojtech Pavlik escribió:
>> On Thu, Jan 31, 2008 at 01:18:22AM +0800, Bryan Wu wrote:
>>
>>> +static irqreturn_t opencores_kbd_isr(int irq, void *dev_id)
>>> +{
>>&g
assumes 1:1 mapping between Linux keycodes
and what the keyboard sends, which I can't believe is the case.
--
Vojtech Pavlik
Director SuSE Labs
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo inf
7;t know about such devices. The device I actually have, an infrared
> remote control, seems simple enough to use the input device model. I
> have a wheel on it but I think I can make it work too...
Yes, wheel isn't a problem. I should have said 'input events'.
--
Vojtec
On Tue, Jan 22, 2008 at 10:47:22AM +0100, Francis Moreau wrote:
> On Jan 22, 2008 9:19 AM, Vojtech Pavlik <[EMAIL PROTECTED]> wrote:
> > On Tue, Jan 22, 2008 at 09:01:10AM +0100, Francis Moreau wrote:
> > > Hello,
> > >
> > > I'd like to add
.
> Do you think it's still the way to go despite the 2 points raised above ?
It might be, but I'm not 100% convinced either.
--
Vojtech Pavlik
Director SuSE Labs
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL
.
>
> On Intel Core2 without RDTSCP the CPUID can be still intercepted right
> now, but the real fix there is to readd FEATURE_SYNC_TSC for Core2 --
> the RDTSC there is always monotonic per CPU and the patch that changed
> that (f3d73707a1e84f0687a05144b70b660441e999c7) was
own in alps-packets.log (I can submit this patch if you deem it
> useful too). It was once I did this that I saw straight away what the
> bit0 had to be. And then mouse.alps.log is just i8042.debug output
> after my patch has been applied.
>
> William
>
> Vojtech Pavlik wrot
00 +1000
> @@ -53,6 +53,7 @@
> { { 0x20, 0x02, 0x0e }, 0xf8, 0xf8, ALPS_PASS | ALPS_DUALPOINT }, /*
> XXX */
> { { 0x22, 0x02, 0x0a }, 0xf8, 0xf8, ALPS_PASS | ALPS_DUALPOINT },
> { { 0x22, 0x02, 0x14 }, 0xff, 0xff, ALPS_PASS | ALPS_DUALPOINT }, /*
> Dell Latitu
tself is not there.
In my opinion, encrypted hibernation is what every notebook user should
want - that's the only way how to make sure data from the notebook
aren't available when the notebook is physically stolen.
--
Vojtech Pavlik
Director SuSE Labs
-
To unsubscribe from this list:
> Does your keyboard start working if you boot with i8042.noaux?
--
Vojtech Pavlik
Director SuSE Labs
-
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/
I may be missing the whole point. I would appreciate your
> >comments on this.
> >
>
> The handler does handle the interrupt - both status and data registers
> are read so from the keyboard controller point of view the interrupt
> has been handled even if we happen to discard
hose options are
> > checked). This patch adds a command-line option "i8042.disable", which just
> > completely disables any checking for the i8042 controller.
>
> That's an unfortunate fix. Is there really no way in which we
> can auto-detect such a situatio
rs
are console and which are not.
> I'll see about writing something up when I get back to my computers[1]
> and have things set back up[2].
Enjoy whatever computerless period you're planning!
--
Vojtech Pavlik
Director SuSE Labs
-
To unsubscribe from this list: send the line
se keys go to the X server via the
console, and GPM also knows about console switching ...
That is a sane way how to prevent the regular console from getting
keypresses/mouse movements.
--
Vojtech Pavlik
Director SuSE Labs
-
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/
, added.
> >>
> >
> >Yep, just send me the patch (don't forget to make change to
> >drivers/char/keyboard.c that Vojtech mentioned in other e-mail).
> >
>
> Here is a patch as promised, attached.
>
> Thanks & Regards,
>
> Hans
Patc
>
> Good to hear, so as everyone smees to agree, shall I write a (massive,
> complex, intrusive) patch to fix this, or are there until now silent
> parties that object?
Just don't forget to update the char/keyboard.c scancode synthesis table
to generate e0 32 for ke
ation layers for PS/2 and would therefore
> assume PS/2 is more inherently correct.
KEY_HOMEPAGE seems to better fit the description of how the key looks.
Microsoft calls it "WWW Home", and it's supposed to be e0 32.
--
Vojtech Pavlik
Director SuSE Labs
-
To unsubscribe from this
thats based on a sample of 1 usb keyboard.
> Input on what other usb keyboards send for the key with the homepage iocn
> is very much welcome.
KEY_HOMEPAGE is likely correct. Maybe we don't want to have KEY_WWW at
all, since it seems to be redundant.
--
Vojtech Pavlik
Director SuSE
usly.
> Using xkb models should work across different OS's, and is available
> now. All that is needed (for ps2 keyboards) is for the path of the
> special keys from the kernel to X-server to not change the codes.
Yes, the linux kernel solution is linux specific. But a lot of other
in
ave been written by Suse, I assume the tested them and it works
>for them. Does anyone know how suse does this?
I don't think it does work. One of our guys is trying to fix it by
1) Converting the xkb multimedia keyboard descriptions to setkeycodes
descriptions
2) Creat
ak description
for the "Linux keyboard", and then all these problems will go away.
PS.: And it's best to use the 'evdev' driver for X instead the 'kbd'
driver, since that one gets the Linux keycodes directly from the kernel,
without any back/forward translati
ing it at all, if you
> so suggest; should I blacklist it for the distro kernel? Or is there a
> chance that some random USB mouse plugged in would fail to function by
> doing so?
usbmouse and usbkbd are only intended for embedded systems where the
full usbhid doesn't fit and for testi
use it eg. for the key that switches between
internal and external output on laptops, if the laptop generates a
keycode for the key at all. But maybe that function is already taken by
KEY_SWITCHVIDEOMODE ...
--
Vojtech Pavlik
Director SuSE Labs
-
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/
have the slightest idea anymore.
> 3. The number of keymap tables grew considerably ;) Do you think it
> woudl make sense to allocate memory for keymap at device creation time
> and copy selected keymap and them mark all original keymaps as
> __initdata so they are discarded one module
s simply because it hides
> potential bugs (when x is to big).
That would be my only concern - losing compiler warnings.
> And what about the "1%"?
The 1% will need either LLBIT or an extra % 8.
> IMHO BIT should be as simple as possible.
--
Vojtech Pavlik
Director Su
ly nr larger than BITS_PER_LONG),
why not just use the modulo version everywhere?
The only problem I see is that the compiler would not warn where nr IS
too large.
--
Vojtech Pavlik
Director SuSE Labs
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
On Tue, Feb 13, 2007 at 11:38:33PM +0100, Andrea Arcangeli wrote:
> Hi,
>
> On Tue, Feb 13, 2007 at 11:18:48PM +0100, Vojtech Pavlik wrote:
> > It's not inherent to ntpd's design, but the current (which may have been
> > fixed since I looked last) implementati
e NTP PLL in the kernel.
The interaction with ntpd can be fixed and I've done it in the past
once, although the fix wasn't all that nice.
> Safer in general is to use clock_gettime(CLOCK_MONOTONIC, ...) which
> guarantees no interference from ntpd
--
Vojtech Pavlik
Director SuSE
stop going again.
> > >
> > > It would be interesting. Thank you Alan, David!
> >
> > I (and SUSE/Novell) would be happy to help organizing the Kernel Summit
> > in Czech Republic.
I didn't get any response yet to my proposal.
--
Vojtech Pavlik
call read. I had some test code for this situation
> awhile back, so if you get the first part functioning correctly (just a
> clocksource w/o a vread pointer), I'll gladly help you get the vsyscall
> bits working.
>
> thanks
> -john
>
>
--
Vojtech Pavlik
Director
> > > - tv->tv_sec = sec + usec / 100;
> > > - tv->tv_usec = usec % 100;
> > > + sec += nsec / NSEC_PER_SEC;
> > > + nsec %= NSEC_PER_SEC;
> >
> > Using while() here is probably faster (done in vdso patchkit where
> > gtod got mysteriously
rpose, so that applications that rely on TSC break
immediately and not after some time when the error becomes too large.
--
Vojtech Pavlik
Director SuSE Labs
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More
On Tue, Jan 30, 2007 at 01:33:10PM +0100, Alessandro Di Marco wrote:
> Vojtech Pavlik <[EMAIL PROTECTED]> writes:
>
>On Mon, Jan 29, 2007 at 11:42:08PM +0100, Alessandro Di Marco wrote:
>
>> OK, but what about the time-warp problem?. To fix it I need to know w
;
>Just use same time source rest of inputs already do...
>
> OK, but what about the time-warp problem?. To fix it I need to know when the
> system goes to sleep/resumes. In SIN I've solved via the platform driver,
> introducing suspend() resume() callbacks...
Well,
il1: remove_proc_entry("input", proc_bus);
> > return -ENOMEM;
> > diff -ur OLD/include/linux/input.h NEW/include/linux/input.h
> > --- OLD/include/linux/input.h 2007-01-26 16:59:38.0 +0100
> > +++ NEW/include/linux/input.h 2007-01-26 17:31:29.0
n.
>
> It would be interesting. Thank you Alan, David!
I (and SUSE/Novell) would be happy to help organizing the Kernel Summit
in Czech Republic.
--
Vojtech Pavlik
Director SuSE Labs
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a mess
gt; Should I wait for an updated patch that uses hid-debug.h again?
>
> actually that code shouldn't be in a header file at all. It should be
> drivers/hid/hid-debug.c and the Makefile should compile it conditionally
> depending on a Kconfig option.
Agreed. It was a .h file just
tuff disappear
> > completely? What would I use instead?
>
> No, it didn't disappear, it was just moved to include/linux/hid-debug.h.
Do you think that makes sense? It's code, not a header file.
> Should I wait for an updated patch that uses hid-debug.h again?
--
Voj
see if Vojtech could change
> that... The main problem is that not only input lists accept posts
> from subscribers only but they silently drop everything else. Maybe
> dropping only HTML posts would be a decent compromise.
Ok. I'll take a look at it.
--
Vojtech Pavlik
Director SuSE Lab
On Fri, Sep 09, 2005 at 12:59:04PM +0200, Karsten Wiese wrote:
> The legacy PIC's name is "i8259".
>
> Signed-off-by: Karsten Wiese <[EMAIL PROTECTED]>
Indeed, i82559 is an Ethernet NIC.
Signed-off-by: Vojtech Pavlik <[EMAIL PROTECTED]>
> diff -upr linu
t; Aivils Stoss
>
>
> While trying this with 2.6.12 it gets a compilation
> error. Not when you move the added statements after
> the structure declaration.
>
> Is that me heading for them thar hills?
The patch probably wasn't tested. ;)
--
Vojtech Pavlik
SuSE Labs, SuSE
rkqueue("kpsmoused");
> + if (!kpsmoused_wq) {
> + printk(KERN_ERR "psmouse: failed to create kpsmoused
> workqueue\n");
> + return -ENOMEM;
> + }
> +
> serio_register_driver(&psmouse_drv);
> +
> return 0;
&
1 - 100 of 554 matches
Mail list logo
