public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Adrian Bunk <bunk@stusta.de>
To: Alessandro Zummo <alessandro.zummo@towertech.it>
Cc: Andrew Morton <akpm@osdl.org>,
	linux-kernel@vger.kernel.org, Greg KH <greg@kroah.com>,
	Russell King <rmk@arm.linux.org.uk>
Subject: Re: 2.6.16-rc4-mm2: drivers/rtc/utils.c should become part of a generic implementation
Date: Sat, 25 Feb 2006 14:10:25 +0100	[thread overview]
Message-ID: <20060225131025.GK3674@stusta.de> (raw)
In-Reply-To: <20060225054619.149db264@inspiron>

On Sat, Feb 25, 2006 at 05:46:19AM +0100, Alessandro Zummo wrote:
> On Sat, 25 Feb 2006 04:31:18 +0100
> Adrian Bunk <bunk@stusta.de> wrote:
> 
> > Always building drivers/rtc/utils.o even if no RTC support is enabled 
> > seems to be a workaround for an issue that should instead be fixed 
> > properly:
> > 
> > The code in e.g. fs/udf/udftime.c or drivers/scsi/ips.c has some 
> > overlaps with what you are adding (they are not doing exactly the 
> > same, but there are overlaps).
> > 
> > We should have one common set of defines/inlines/functions dealing with 
> > all these time conversion, leap year, length of months/years etc. issues 
> > instead of adding one more implementation in this area.
> 
>  I agree. My idea was to place those routines in utils.o and then
>  modify callers, like udftime.c and ips.c to use them. What is currently
>  in utils.c has been gathered from files that were known to me,
>  lice rtctime.c in the arm arch and some rtc drivers. Once deployed,
>  it will be easier to find and convert similar routines.y

Sounds good, but for generic functions, two adjustments are required:
- move the code to lib/
- remove rtc_ prefixes from the functions

>  Best regards,
>  Alessandro Zummo,

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed


  reply	other threads:[~2006-02-25 13:10 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-02-24 11:10 2.6.16-rc4-mm2 Andrew Morton
2006-02-24 16:27 ` [-mm PATCH] mips: fixed collision of rtc function name Yoichi Yuasa
2006-02-25 13:48   ` Atsushi Nemoto
2006-02-26 22:43     ` Yoichi Yuasa
2006-03-06 21:12       ` Ralf Baechle
2006-02-24 23:52 ` 2.6.16-rc4-mm2 Sam Ravnborg
2006-02-25  3:31 ` 2.6.16-rc4-mm2: drivers/rtc/utils.c should become part of a generic implementation Adrian Bunk
2006-02-25  4:46   ` Alessandro Zummo
2006-02-25 13:10     ` Adrian Bunk [this message]
2006-02-26 18:41       ` Alessandro Zummo
2006-02-26 18:55         ` Adrian Bunk
2006-02-26 20:02           ` Russell King
2006-03-03 22:26             ` Adrian Bunk
2006-02-25  3:38 ` 2.6.16-rc4-mm2: drivers/isdn/hysdn/hysdn_net.c module_param() compile error Adrian Bunk
2006-02-25  7:10   ` Rusty Russell
2006-02-25  7:22   ` Andrew Morton
2006-02-25  7:56     ` Rusty Russell
2006-02-25  3:47 ` oss/sonicvibes.c defines its own hweight32 Richard Knutsson
2006-02-25  4:11 ` 2.6.16-rc4-mm2: useless acpi_pmtmr_buggy Adrian Bunk
2006-02-25 11:59 ` 2.6.16-rc4-mm2 Jesper Juhl
2006-02-25 12:17   ` 2.6.16-rc4-mm2 Andrew Morton
2006-02-25 12:25     ` 2.6.16-rc4-mm2 Jesper Juhl
2006-02-25 12:31       ` 2.6.16-rc4-mm2 Andrew Morton
2006-02-25 12:41         ` 2.6.16-rc4-mm2 Jesper Juhl
2006-02-25 15:51           ` 2.6.16-rc4-mm2 Jesper Juhl
2006-02-26 23:38           ` 2.6.16-rc4-mm2 Antonino A. Daplas
2006-02-25 13:15 ` [-mm patch] drivers/media/video/cpia2/cpia2_v4l.c cleanups Adrian Bunk
2006-02-25 13:18 ` [-mm patch] kernel/params.c: make param_array() static Adrian Bunk
2006-02-25 13:21 ` [-mm patch] drivers/rtc/: make some structs static Adrian Bunk
2006-02-25 13:24 ` [-mm patch] kernel/fork.c: make signal_cachep static Adrian Bunk
2006-02-25 13:27 ` [-mm patch] net/dccp/ipv4.c: make struct dccp_v4_prot static Adrian Bunk
2006-02-25 14:31   ` Arnaldo Carvalho de Melo
2006-02-25 13:45 ` usbfs2 panic [Was: 2.6.16-rc4-mm2] Jiri Slaby
2006-02-25 18:05   ` Greg KH

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20060225131025.GK3674@stusta.de \
    --to=bunk@stusta.de \
    --cc=akpm@osdl.org \
    --cc=alessandro.zummo@towertech.it \
    --cc=greg@kroah.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=rmk@arm.linux.org.uk \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox