Linux MIPS Architecture development
 help / color / mirror / Atom feed
From: ilya@theIlya.com
To: Christoph Hellwig <hch@infradead.org>
Cc: linux-mips@linux-mips.org, ralf@linux-mips.org
Subject: Re: O2 VICE support
Date: Wed, 11 Dec 2002 14:16:29 -0800	[thread overview]
Message-ID: <20021211221629.GP609@gateway.total-knowledge.com> (raw)
In-Reply-To: <20021211133831.A19300@infradead.org>

[-- Attachment #1: Type: text/plain, Size: 2613 bytes --]

> Urgg.  Usually kernel headers aren't supposed to be used in userspace.
> If you want to use a copy anyway it should be done with much less burden
> on the kernel code.
Well, most of manipulation of this device will be done bu user-space
code. Kernel's only job is synchronising access and managing memory.
Thus we would like to keep all definitions in one place.

> > +    if (!filp->private_data) {
> > +	filp->private_data = vice_device;
> > +    }
> 
> filp->private_data can't be set.
???
I can live without using it of course, since it isn't currently possible to have
more then one instance of VICE in same machine, but theoretical possibility does
exist. Where should I pass information about which specific device current
call is?

> 
> > +ssize_t vice_read(struct file * filp, char *buf, size_t count, loff_t * f_pos)
> > +{
> > +    printk(KERN_WARNING
> > +	   "Processing bit streams through reading/writing is not supported yet\n");
> > +    return -ENOSYS;
> > +}
> > +
> > +ssize_t vice_write(struct file * filp, const char *buf, size_t count,
> > +	   loff_t * f_pos)
> > +{
> > +    printk(KERN_WARNING
> > +	   "Processing bit streams through reading/writing is not supported (yet)\n");
> > +    return -ENOSYS;
> > +}
> 
> What about just not implementing the methods instead?
This is more like reminder to myself that I should do that one day :)

> > +static void vice_vma_open(struct vm_area_struct *vma)
> > +{ MOD_INC_USE_COUNT; }
> > +
> > +static void vice_vma_close(struct vm_area_struct *vma)
> > +{ MOD_DEC_USE_COUNT; }
> 
> This is silly.  You get a reference for vma->vm_file as long as you
> have any mmaps.  That's enough for the refcounting.
I was wondering about that too, but this is the way i was in book :)

> 
> > +static struct vm_operations_struct vice_vm_ops = {
> > +    open:  vice_vma_open,
> > +    close: vice_vma_close,
> > +    nopage: vice_vma_nopage,
> > +};
> 
> Please use C99-initializers (i.e. .foo = bar)
> 
> > +void vice_cleanup_module(void)
> > +{
> > +#ifndef CONFIG_DEVFS_FS
> > +    /* cleanup_module is never called if registering failed */
> > +    unregister_chrdev(vice_major, "vice");
> > +#endif
> 
> Umm, just because someone makes the mistake of enabling devfs he
> doesn't have to use it.. :)
I'm not buying that one :)

> 
> > +#ifndef VICE_DEBUG
> > +    EXPORT_NO_SYMBOLS;		/* otherwise, leave global symbols visible */
> > +#endif
> 
> EXPORT_NO_SYMBOLS is a noop on 2.5
Driver was written for 2.4 first.


Thanks a lot for constructive criticism.

	Ilya.


[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

  reply	other threads:[~2002-12-11 22:16 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-12-10 19:11 O2 VICE support ilya
2002-12-11 13:38 ` Christoph Hellwig
2002-12-11 22:16   ` ilya [this message]
2002-12-11 22:45     ` Christoph Hellwig
2002-12-11 22:46     ` Juan Quintela
2002-12-22  9:20 ` Geert Uytterhoeven

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=20021211221629.GP609@gateway.total-knowledge.com \
    --to=ilya@theilya.com \
    --cc=hch@infradead.org \
    --cc=linux-mips@linux-mips.org \
    --cc=ralf@linux-mips.org \
    /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