and then the current thread's running KUnit test.
Add a safe wrapper function around this to know whether or not we are in
a KUnit test and examples showing how to mock a function and a module.
Signed-off-by: José Expósito
Co-developed-by: Miguel Ojeda
Signed-off-by: Miguel Ojeda
Co-deve
ion kernels, so checking at
> > > > runtime
> > > > that `current->kunit_test != NULL` is required.
> > > >
> > > > Forturately, KUnit provides an optimised check in
> > > > `kunit_get_current_test()`, which checks CONFIG_KUNIT, a global stati
imised check in
> > > `kunit_get_current_test()`, which checks CONFIG_KUNIT, a global static
> > > key, and then the current thread's running KUnit test.
> > >
> > > Add a safe wrapper function around this to know whether or not we are in
> > > a K
and then the current thread's running KUnit test.
Add a safe wrapper function around this to know whether or not we are in
a KUnit test and examples showing how to mock a function and a module.
Signed-off-by: José Expósito
Co-developed-by: Miguel Ojeda
Signed-off-by: Miguel Ojeda
Co-deve
KUnit in production kernels, so checking at runtime
> > that `current->kunit_test != NULL` is required.
> >
> > Forturately, KUnit provides an optimised check in
> > `kunit_get_current_test()`, which checks CONFIG_KUNIT, a global static
> > key, and then the current thre
urately, KUnit provides an optimised check in
> `kunit_get_current_test()`, which checks CONFIG_KUNIT, a global static
> key, and then the current thread's running KUnit test.
>
> Add a safe wrapper function around this to know whether or not we are in
> a KUnit test and examples sho
and then the current thread's running KUnit test.
Add a safe wrapper function around this to know whether or not we are in
a KUnit test and examples showing how to mock a function and a module.
Signed-off-by: José Expósito
Co-developed-by: David Gow
Signed-off-by: David Gow
Co-developed-by
On Fri, Dec 13, 2024 at 9:10 AM David Gow wrote:
>
> +/// In some cases, you need to call test-only code from outside the test
> case, for example, to
> +/// create a function mock. This function can be invoked to know whether we
> are currently running a
> +/// KUnit
and then the current thread's running KUnit test.
Add a safe wrapper function around this to know whether or not we are in
a KUnit test and examples showing how to mock a function and a module.
Signed-off-by: José Expósito
Co-developed-by: David Gow
Signed-off-by: David Gow
---
Changes
On Fri, Nov 01, 2024 at 02:45:02PM +0800, David Gow wrote:
[...]
> +/// ```
> +/// // Import our mock naming it as the real module.
> +/// #[cfg(CONFIG_KUNIT)]
> +/// use bindings_mock_example as bindings;
> +///
> +/// // This module mocks `bindings`.
> +/// mod bindings_mock_example {
> +///
and then the current thread's running KUnit test.
Add a safe wrapper function around this to know whether or not we are in
a KUnit test and examples showing how to mock a function and a module.
Signed-off-by: José Expósito
Co-developed-by: David Gow
Signed-off-by: David Gow
---
Changes
and then the current thread's running KUnit test.
Add a safe wrapper function around this to know whether or not we are in
a KUnit test and examples showing how to mock a function and a module.
Signed-off-by: José Expósito
Co-developed-by: David Gow
Signed-off-by: David Gow
---
No changes
and then the current thread's running KUnit test.
Add a safe wrapper function around this to know whether or not we are in
a KUnit test and examples showing how to mock a function and a module.
Signed-off-by: José Expósito
Co-developed-by: David Gow
Signed-off-by: David Gow
---
Changes
This use devfreq variable that will be lock with spinlock in future
patches. We should either introduce a function to access this one
but as devfreq is optional let's just remove it.
Reviewed-by: Steven Price
Reviewed-by: Alyssa Rosenzweig
Signed-off-by: Clément Péron
---
drivers/gpu/drm/panfr
This use devfreq variable that will be lock with spinlock in future
patches. We should either introduce a function to access this one
but as devfreq is optional let's just remove it.
Reviewed-by: Steven Price
Reviewed-by: Alyssa Rosenzweig
Signed-off-by: Clément Péron
---
drivers/gpu/drm/panfr
This use devfreq variable that will be lock with spinlock in future
patches. We should either introduce a function to access this one
but as devfreq is optional let's just remove it.
Reviewed-by: Steven Price
Reviewed-by: Alyssa Rosenzweig
Signed-off-by: Clément Péron
---
drivers/gpu/drm/panfr
This use devfreq variable that will be lock with spinlock in future
patches. We should either introduce a function to access this one
but as devfreq is optional let's just remove it.
Signed-off-by: Clément Péron
Reviewed-by: Steven Price
---
drivers/gpu/drm/panfrost/panfrost_job.c | 4
1 f
On 10/05/2020 17:55, Clément Péron wrote:
This use devfreq variable that will be lock with spinlock in future
patches. We should either introduce a function to access this one
but as devfreq is optional let's just remove it.
Signed-off-by: Clément Péron
As far as I can tell this should be saf
This use devfreq variable that will be lock with spinlock in future
patches. We should either introduce a function to access this one
but as devfreq is optional let's just remove it.
Signed-off-by: Clément Péron
---
drivers/gpu/drm/panfrost/panfrost_job.c | 4
1 file changed, 4 deletions(-)
From: Lary Gibaud
commit e450e07c14abae563ad13b064cbce9fdccc6bc8d upstream.
Indeed, relying on addr being not 0 cannot work because some device have
their register to set odr at address 0. As a matter of fact, if the odr
can be set, then there is a mask.
Sensors with ODR register at address 0 a
From: Lary Gibaud
commit e450e07c14abae563ad13b064cbce9fdccc6bc8d upstream.
Indeed, relying on addr being not 0 cannot work because some device have
their register to set odr at address 0. As a matter of fact, if the odr
can be set, then there is a mask.
Sensors with ODR register at address 0 a
From: Lary Gibaud
commit e450e07c14abae563ad13b064cbce9fdccc6bc8d upstream.
Indeed, relying on addr being not 0 cannot work because some device have
their register to set odr at address 0. As a matter of fact, if the odr
can be set, then there is a mask.
Sensors with ODR register at address 0 a
Greetings,
I am Mr.Abdelkader Alsamman from Syria,It's possible for a
foreigner to invest in education in your country?let me know the
feasibility studies as I want to relocate my investment to your
country and I need a local partner because I want to relocate my
family out from Syria due to t
And add some description translation in index file.
Signed-off-by: Alex Shi
Cc: Harry Wei
Cc: Jonathan Corbet
Cc: Li Zefan
Cc: Shawn Guo
Cc: Fengguang Wu
Cc: Coly Li
---
Documentation/translations/zh_CN/index.rst | 17 +
1 file changed, 13 insertions(+), 4 deletions(-)
dif
And add some description translation in index file.
Signed-off-by: Alex Shi
Cc: Harry Wei
Cc: Jonathan Corbet
Cc: Li Zefan
Cc: Shawn Guo
Cc: Fengguang Wu
Cc: Coly Li
---
Documentation/translations/zh_CN/index.rst | 17 +
1 file changed, 13 insertions(+), 4 deletions(-)
dif
And add some description translation in index file.
Signed-off-by: Alex Shi
Cc: Harry Wei
Cc: Jonathan Corbet
Cc: Li Zefan
Cc: Shawn Guo
Cc: Fengguang Wu
Cc: Coly Li
---
Documentation/translations/zh_CN/index.rst | 17 +
1 file changed, 13 insertions(+), 4 deletions(-)
dif
;> calling the shutdown function after costly operations. It could be
>>> interesting to check if there is a pending interrupt before initiating
>>> the power down sequence.
>>>
>>> Is there a way to know if there is a pending interrupt on the current
>>> CPU
ere is a pending interrupt before initiating
>> the power down sequence.
>>
>> Is there a way to know if there is a pending interrupt on the current
>> CPU when the local interrupt are disabled? Something like,
>> local_irq_pending() function ?
>
> We have nothing l
nding interrupt before initiating
>> the power down sequence.
>>
>> Is there a way to know if there is a pending interrupt on the current
>> CPU when the local interrupt are disabled? Something like,
>> local_irq_pending() function ?
>
> We have nothing like that today,
nding interrupt this one
> will make the power down function to abort, thus exiting right after
> calling the shutdown function after costly operations. It could be
> interesting to check if there is a pending interrupt before initiating
> the power down sequence.
>
> Is there a
abort, thus exiting right after
calling the shutdown function after costly operations. It could be
interesting to check if there is a pending interrupt before initiating
the power down sequence.
Is there a way to know if there is a pending interrupt on the current
CPU when the local interrupt are
My Dear, Good day to you
I got my contact via the internet database of your country,
My name is Mr. Rungsun Klinkaeo, from Thailand and lawyer, to Late
Engineer Vladimir D. Soloviev, a citizen of your country who was lived
in Petrograd, Russia.
I am writing to present you as a relative to a La
On Wed, Oct 25, 2017 at 11:04:43AM +0200, Ingo Molnar wrote:
>
> * Paul E. McKenney wrote:
>
> > On Wed, Oct 25, 2017 at 10:45:48AM +0200, Ingo Molnar wrote:
> > >
> > > * Paul E. McKenney wrote:
> > >
> > > > Hello, Ingo,
> > > >
> > > > This series is a first step towards making the core k
* Paul E. McKenney wrote:
> On Wed, Oct 25, 2017 at 10:45:48AM +0200, Ingo Molnar wrote:
> >
> > * Paul E. McKenney wrote:
> >
> > > Hello, Ingo,
> > >
> > > This series is a first step towards making the core kernel no longer
> > > need to consider DEC Alpha as a special case. This is acco
On Wed, Oct 25, 2017 at 10:45:48AM +0200, Ingo Molnar wrote:
>
> * Paul E. McKenney wrote:
>
> > Hello, Ingo,
> >
> > This series is a first step towards making the core kernel no longer
> > need to consider DEC Alpha as a special case. This is accomplished
> > by two sets of patches, followed
* Paul E. McKenney wrote:
> Hello, Ingo,
>
> This series is a first step towards making the core kernel no longer
> need to consider DEC Alpha as a special case. This is accomplished
> by two sets of patches, followed by a Coccinelle script:
>
> 1.Patches 1/19 through 15/19 in the followi
* Paul E. McKenney wrote:
> Mark Rutland (14):
> dm integrity: Kill off ACCESS_ONCE()
> EDAC, altera: Kill off ACCESS_ONCE()
> firmware/ivc: Kill off ACCESS_ONCE()
> fs: dcache: Kill off ACCESS_ONCE()
> fs: ncpfs: Kill off ACCESS_ONCE()
> media: dvb_ringbuffer
Hello, Ingo,
This series is a first step towards making the core kernel no longer
need to consider DEC Alpha as a special case. This is accomplished
by two sets of patches, followed by a Coccinelle script:
1. Patches 1/19 through 15/19 in the following patches, which
change non-Cocc
My Dear,
>From Mrs. Loveth Konnia.
I belief that you can help in setting up a charity foundation for the
benefit of mankind, I wish to establish a charity foundation to help
the poor in your country under your care, Can you help to build this
project in your country? Together We can make the wor
From: Fenghua Yu
We saw a kernel oops on NULL pointer when we ran "rmdir info". This is
because the "info" directory and per-resource subdirectories of "info"
do not use "kn->priv" to point to a "struct rdtgroup".
Also change error code from -ENOENT to the more appropriate -EPERM
so the user see
On Thu, Apr 07, 2016 at 08:17:25PM +0200, Martin Fuzzey wrote:
> On 07/04/16 19:02, Mark Brown wrote:
> >No, this is not sensible. You should be telling the framework about the
> >slew rate and letting the framework work out how long it's going to take
> >to transition. Your driver shouldn't be
Thanks for your reply.
On 07/04/16 19:02, Mark Brown wrote:
On Thu, Apr 07, 2016 at 03:25:09PM +0200, Martin Fuzzey wrote:
To implement the .enable_time() method I need the voltage (which is
the supply's voltage).
No, this is not sensible. You should be telling the framework about the
slew r
On Thu, Apr 07, 2016 at 03:25:09PM +0200, Martin Fuzzey wrote:
> To implement the .enable_time() method I need the voltage (which is
> the supply's voltage).
No, this is not sensible. You should be telling the framework about the
slew rate and letting the framework work out how long it's going t
Hi,
I am working on a driver for the tps22993 load switch.
This chip has configurable slew rates but no voltage setting
(as it's just a switch).
To implement the .enable_time() method I need the voltage (which is
the supply's voltage).
The problem is that, when my regulator is configured as al
14 08:52 AM, Joonsoo Kim wrote:
> > >> > It'd be useful to know where the both scanner is start. And, it also be
> > >> > useful to know current range where compaction work. It will help to
> > >> > find
> > >> > odd behaviour or proble
On Thu, Jan 08, 2015 at 09:46:27AM +0100, Vlastimil Babka wrote:
> On 01/08/2015 09:18 AM, Joonsoo Kim wrote:
> > On Tue, Jan 06, 2015 at 10:05:39AM +0100, Vlastimil Babka wrote:
> >> On 12/03/2014 08:52 AM, Joonsoo Kim wrote:
> >> > It'd be useful to know where
On Thu, Jan 08, 2015 at 09:46:27AM +0100, Vlastimil Babka wrote:
> On 01/08/2015 09:18 AM, Joonsoo Kim wrote:
> > On Tue, Jan 06, 2015 at 10:05:39AM +0100, Vlastimil Babka wrote:
> >> On 12/03/2014 08:52 AM, Joonsoo Kim wrote:
> >> > It'd be useful to know where
On 01/08/2015 09:18 AM, Joonsoo Kim wrote:
> On Tue, Jan 06, 2015 at 10:05:39AM +0100, Vlastimil Babka wrote:
>> On 12/03/2014 08:52 AM, Joonsoo Kim wrote:
>> > It'd be useful to know where the both scanner is start. And, it also be
>> > useful to know current rang
On Tue, Jan 06, 2015 at 10:05:39AM +0100, Vlastimil Babka wrote:
> On 12/03/2014 08:52 AM, Joonsoo Kim wrote:
> > It'd be useful to know where the both scanner is start. And, it also be
> > useful to know current range where compaction work. It will help to find
> > o
On 12/03/2014 08:52 AM, Joonsoo Kim wrote:
> It'd be useful to know where the both scanner is start. And, it also be
> useful to know current range where compaction work. It will help to find
> odd behaviour or problem on compaction.
Overall it looks good, just two questions:
1)
On 01/05/2015 03:33 AM, Joonsoo Kim wrote:
> On Wed, Dec 03, 2014 at 04:52:05PM +0900, Joonsoo Kim wrote:
>> It'd be useful to know where the both scanner is start. And, it also be
>> useful to know current range where compaction work. It will help to find
>> odd behaviou
On Wed, Dec 03, 2014 at 04:52:05PM +0900, Joonsoo Kim wrote:
> It'd be useful to know where the both scanner is start. And, it also be
> useful to know current range where compaction work. It will help to find
> odd behaviour or problem on compaction.
>
> Signed-off-by:
It'd be useful to know where the both scanner is start. And, it also be
useful to know current range where compaction work. It will help to find
odd behaviour or problem on compaction.
Signed-off-by: Joonsoo Kim
---
include/linux/compaction.h|2 +
include/trace/events/compact
--
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/
Dear Sirs,
Pleased to get your contact information...
we are established in 2004, Manufacturer of plastic prescription vial, bottle.
includes: Child Resistant cap, Reversible Cap, Snap Cap, Oval bottle...FDA
approved.
We are capable to provide you good quality products, Our main market is Us
On Wednesday 11 December 2013 02:23 PM, Heikki Krogerus wrote:
> Hi,
>
> On Mon, Dec 09, 2013 at 11:26:04AM +0200, Heikki Krogerus wrote:
>> Can you guys explain why is something like this needed? Like with
>> clocks and gpios, the device drivers shouldn't need to care any more
>> if t
Hi,
On Mon, Dec 09, 2013 at 11:26:04AM +0200, Heikki Krogerus wrote:
> > >>>Can you guys explain why is something like this needed? Like with
> > >>>clocks and gpios, the device drivers shouldn't need to care any more
> > >>>if the platform has the phys or not. -ENODEV tells you your platform
> >
Hi,
This replaces the consumer & init_data structures with a lookup table
that contains complete associations with the phys and their users,
removing the need for the phy drivers themselves to care about their
users even when not using DT.
The lookup method is copied from the way the gpio descrip
Hi,
On Mon, Dec 09, 2013 at 12:43:37PM +0530, Kishon Vijay Abraham I wrote:
> On Thursday 05 December 2013 01:28 PM, Heikki Krogerus wrote:
> >On Thu, Dec 05, 2013 at 12:04:46PM +0530, Kishon Vijay Abraham I wrote:
> >>On Wednesday 04 December 2013 08:10 PM, Heikki Krogerus wrote:
> >>>On Mon, Nov
Hi,
On Thursday 05 December 2013 01:28 PM, Heikki Krogerus wrote:
Hi,
On Thu, Dec 05, 2013 at 12:04:46PM +0530, Kishon Vijay Abraham I wrote:
On Wednesday 04 December 2013 08:10 PM, Heikki Krogerus wrote:
On Mon, Nov 25, 2013 at 03:31:24PM +0530, Kishon Vijay Abraham I wrote:
There can be sy
Hi,
On Thu, Dec 05, 2013 at 12:04:46PM +0530, Kishon Vijay Abraham I wrote:
> On Wednesday 04 December 2013 08:10 PM, Heikki Krogerus wrote:
> > On Mon, Nov 25, 2013 at 03:31:24PM +0530, Kishon Vijay Abraham I wrote:
> >> There can be systems which does not have an external phy, so get
> >> phy on
Hi,
On Wednesday 04 December 2013 08:10 PM, Heikki Krogerus wrote:
> Hi guys,
>
> Kishon, sorry I did not see this v3 set.
>
> On Mon, Nov 25, 2013 at 03:31:24PM +0530, Kishon Vijay Abraham I wrote:
>> There can be systems which does not have an external phy, so get
>> phy only if no quirks are
Hi guys,
Kishon, sorry I did not see this v3 set.
On Mon, Nov 25, 2013 at 03:31:24PM +0530, Kishon Vijay Abraham I wrote:
> There can be systems which does not have an external phy, so get
> phy only if no quirks are added that indicates the PHY is not present.
> Introduced two quirk flags to ind
On Mon, Nov 25, 2013 at 03:31:24PM +0530, Kishon Vijay Abraham I wrote:
> There can be systems which does not have an external phy, so get
> phy only if no quirks are added that indicates the PHY is not present.
> Introduced two quirk flags to indicate the *absence* of usb2 phy and
> usb3 phy. Also
There can be systems which does not have an external phy, so get
phy only if no quirks are added that indicates the PHY is not present.
Introduced two quirk flags to indicate the *absence* of usb2 phy and
usb3 phy. Also remove checking if return value is -ENXIO since it's now
changed to always enab
I Will Be Glad To Know You,
I am Sandy. Please, I will like to be your friend only if you don't mind,
contact me for my picture
and more about me,
Thanks in advance and remain blessed!
Sandy.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body
--
Hello, My sincere apology contating you in this manner without getting to know
you properly before now,I'm mailling
you this letter base on my health condition seeking the attention of Godly
minded personto handle humanitarian project in my name. Am Gillian Billy on sick
bed in St Bro
This patch uses the recently added config sybmol ARCH_HAS_BANDGAP to enable
the TMU driver. This will allow adding support for new soc easily as now it
is the platform responsibility to enable this config symbol for a particular
soc.
Acked-by: Kukjin Kim
Acked-by: Jonghwa Lee
Acked-by: Eduardo V
On 17-06-2013 02:46, Amit Daniel Kachhap wrote:
> This patch uses the recently added config sybmol ARCH_HAS_BANDGAP to enable
> the TMU driver. This will allow adding support for new soc easily as now it
> is the platform responsibility to enable this config symbol for a particular
> soc.
>
> Acke
This patch uses the recently added config sybmol ARCH_HAS_BANDGAP to enable
the TMU driver. This will allow adding support for new soc easily as now it
is the platform responsibility to enable this config symbol for a particular
soc.
Acked-by: Kukjin Kim
Acked-by: Jonghwa Lee
Signed-off-by: Amit
Hi Eduardo,
On Mon, Jun 17, 2013 at 8:35 AM, Eduardo Valentin
wrote:
> Hey Amit,
>
> On 11-06-2013 08:53, Amit Daniel Kachhap wrote:
>> This patch adds config sybmol ARCH_HAS_TMU to enable the TMU driver.
>> This will allow adding support for new soc easily as now it is the
>> platform responsibi
Hey Amit,
On 11-06-2013 08:53, Amit Daniel Kachhap wrote:
> This patch adds config sybmol ARCH_HAS_TMU to enable the TMU driver.
> This will allow adding support for new soc easily as now it is the
> platform responsibility to enable this config symbol.
>
> Acked-by: Kukjin Kim
> Signed-off-by:
This patch adds config sybmol ARCH_HAS_TMU to enable the TMU driver.
This will allow adding support for new soc easily as now it is the
platform responsibility to enable this config symbol.
Acked-by: Kukjin Kim
Signed-off-by: Amit Daniel Kachhap
---
drivers/thermal/samsung/Kconfig |5 -
This patch adds config sybmol ARCH_HAS_TMU to enable the TMU driver.
This will allow adding support for new soc easily as now it is the
platform responsibility to enable this config symbol.
Acked-by: Kukjin Kim
Signed-off-by: Amit Daniel Kachhap
---
drivers/thermal/samsung/Kconfig |5 -
On 2012-07-24 09:08, bforce1729 wrote:
Hi,
I am new to kernel programming so can anyone point me to the right
forum/reply for the question below.
I would like to implement a character device and using a node of type
character read and write data. However I am not sure of the length of
data fro
Hi,
I am new to kernel programming so can anyone point me to the right
forum/reply for the question below.
I would like to implement a character device and using a node of type
character read and write data. However I am not sure of the length of
data from kernel which a user app will recei
Hello,
Can anybody explain me how ethernet header is
added to every packet outgoing? I check eth.c file and
found eth_header that is used for adding ethernet
header on skbuff packet. But does each packet calls
this function? I think not as theres a cache header
function used that cache ether
In article <[EMAIL PROTECTED]>,
Harald Welte <[EMAIL PROTECTED]> wrote:
>
>Is there any way to read out the compile-time HZ value of the kernel?
In 2.4.x, you'll get it on the stack as one of the ELF auxilliary
entries (AT_CLKTCK).
Strictly speaking that's the "frequency at which 'times()' cou
On Wed, Jun 06, 2001 at 08:59:51PM +0200, Tomas Telensky wrote:
> > On Wed, Jun 06, 2001 at 08:09:33PM +0200, Tomas Telensky wrote:
> > > > Hi!
> > > >
> > > > Is there any way to read out the compile-time HZ value of the kernel?
> > >
> > > Why simply #include ?
> >
> > because the include fil
> On Wed, Jun 06, 2001 at 08:09:33PM +0200, Tomas Telensky wrote:
> > > Hi!
> > >
> > > Is there any way to read out the compile-time HZ value of the kernel?
> >
> > Why simply #include ?
>
> because the include file doesn't say anything about the HZ value of
> the currently running kernel, bu
On Wed, Jun 06, 2001 at 08:09:33PM +0200, Tomas Telensky wrote:
> > Hi!
> >
> > Is there any way to read out the compile-time HZ value of the kernel?
>
> Why simply #include ?
because the include file doesn't say anything about the HZ value of
the currently running kernel, but only about some
> Hi!
>
> Is there any way to read out the compile-time HZ value of the kernel?
Why simply #include ?
Tomas
>
> I had a brief look at /proc/* and didn't find anything.
>
> The background, why it is needed:
>
> There are certain settings, for example the icmp rate limiting values,
>
On Wed, May 30, 2001 at 08:37:25PM -0300, Harald Welte wrote:
> Hi!
>
> Is there any way to read out the compile-time HZ value of the kernel?
>
> I had a brief look at /proc/* and didn't find anything.
>
> The background, why it is needed:
>
> There are certain settings, for example the icmp r
Followup to: <[EMAIL PROTECTED]>
By author:Ralf Baechle <[EMAIL PROTECTED]>
In newsgroup: linux.dev.kernel
>
> On Wed, May 30, 2001 at 05:07:22PM -0700, H. Peter Anvin wrote:
>
> > Yes, but that's because the interfaces are broken. The decision has
> > been that these values should be expor
On Wed, May 30, 2001 at 05:07:22PM -0700, H. Peter Anvin wrote:
> Yes, but that's because the interfaces are broken. The decision has
> been that these values should be exported using the default HZ for the
> architecture, and that it is the kernel's responsibility to scale them
> when HZ != USE
On Fri, 1 Jun 2001, Peter Waltenberg wrote:
> Yes, I know we have a chance of being rescheduled simply because "something
> else" has also yielded. However thats fairly hit and miss.
>
> I don't disagree with your statement that thats how the interface should be
> designed, but the most of the ap
On Thursday 31 May 2001 02:44, Jonathan Lundell wrote:
> At 1:38 AM +0100 2001-05-31, Joel Becker wrote:
> >On Wed, May 30, 2001 at 05:24:37PM -0700, Jonathan Lundell wrote:
> >> FWIW (perhaps not much in this context), the POSIX way is
> >>sysconf(_SC_CLK_TCK)
> >>
> >> POSIX sysconf is pretty
Followup to: <[EMAIL PROTECTED]>
By author:Harald Welte <[EMAIL PROTECTED]>
In newsgroup: linux.dev.kernel
> >
> > Look again, this time with a sick mind. Got your barf bag?
> > Kubys made me do it.
>
> ;)
>
> First of all thanks for your recommended solution.
>
It's not *recommended*.
On Wed, May 30, 2001 at 11:40:30PM -0400, Albert D. Cahalan wrote:
> Harald Welte writes:
>
> > Is there any way to read out the compile-time HZ value of the kernel?
> >
> > I had a brief look at /proc/* and didn't find anything.
>
> Look again, this time with a sick mind. Got your barf bag?
>
Harald Welte writes:
> Is there any way to read out the compile-time HZ value of the kernel?
>
> I had a brief look at /proc/* and didn't find anything.
Look again, this time with a sick mind. Got your barf bag?
Kubys made me do it.
/
Jonathan Lundell writes:
> At 5:07 PM -0700 2001-05-30, H. Peter Anvin wrote:
>>> If you now want to set those values from a userspace program / script in
>>> a portable manner, you need to be able to find out of HZ of the currently
>>> running kernel.
>>
>> Yes, but that's because the interfac
Joel Becker wrote:
>
> On Wed, May 30, 2001 at 05:24:37PM -0700, Jonathan Lundell wrote:
> > FWIW (perhaps not much in this context), the POSIX way is sysconf(_SC_CLK_TCK)
> >
> > POSIX sysconf is pretty useful for this kind of thing (not just HZ, either).
>
> Well, how many hundred thin
On Wed, May 30, 2001 at 05:44:39PM -0700, Jonathan Lundell wrote:
> Lots. Maybe we oughta have /proc/sysconf/... (there's no reason
> sysconf() can't be a library reading /proc).
You don't mount proc?
mrc
--
Mike Castle [EMAIL PROTECTED] www.netcom.com/~dalgoda/
We are all o
At 1:38 AM +0100 2001-05-31, Joel Becker wrote:
>On Wed, May 30, 2001 at 05:24:37PM -0700, Jonathan Lundell wrote:
>> FWIW (perhaps not much in this context), the POSIX way is
>>sysconf(_SC_CLK_TCK)
>>
>> POSIX sysconf is pretty useful for this kind of thing (not just HZ, either).
>
> Wel
On Wed, May 30, 2001 at 05:24:37PM -0700, Jonathan Lundell wrote:
> FWIW (perhaps not much in this context), the POSIX way is sysconf(_SC_CLK_TCK)
>
> POSIX sysconf is pretty useful for this kind of thing (not just HZ, either).
Well, how many hundred things on Linux are available from /p
At 5:07 PM -0700 2001-05-30, H. Peter Anvin wrote:
> > If you now want to set those values from a userspace program / script in
>> a portable manner, you need to be able to find out of HZ of the currently
>> running kernel.
>>
>
>Yes, but that's because the interfaces are broken. The decision
one in this
> area.
Pardon, but that still seems broken to me. USER_HZ shouldn't
matter to the architecture either. I would think that if
'echo 10 > /proc/foo/icmp_foo' sets a timeout of 10ms on alpha, it
should also do so on x86, sparc, and mips. Why should the usersp
Followup to: <[EMAIL PROTECTED]>
By author:Harald Welte <[EMAIL PROTECTED]>
In newsgroup: linux.dev.kernel
>
> Is there any way to read out the compile-time HZ value of the kernel?
>
> I had a brief look at /proc/* and didn't find anything.
>
> The background, why it is needed:
>
> There
Hi!
Is there any way to read out the compile-time HZ value of the kernel?
I had a brief look at /proc/* and didn't find anything.
The background, why it is needed:
There are certain settings, for example the icmp rate limiting values,
which can be set using sysctl. Those setting are basically
1 - 100 of 104 matches
Mail list logo
