IRC channel logs


back to list of logs

<jrtc27>if you're editing an existing function, follow the function's style
<jrtc27>adding to a file, use the file's style
<AlmuHS>but most of my work is in new files
<jrtc27>adding to a directory, use the style of the other files in that directory
<jrtc27>adding a new directory, whatever the parent directory uses
<AlmuHS>yes, but in the same directory are many files with many different formatting and styles
<jrtc27>so go with the majority
<jrtc27>and if in doubt, pick either GNU or mach
<jrtc27>I personally think mach is the right one to use in the situation, but GNU isn't necessarily *wrong*, that comes down more to personal preference
<AlmuHS>I tried to follow GNU style, with the tips that youpi told me some months ago
<jrtc27>(and what I think doesn't matter; youpi's the one to please)
<jrtc27>yeah but you didn't, you have tabs where there should be spaces, indents that are too big and vary within the same function, spaces missing before ('s
<jrtc27>I don't remember any specifics
<AlmuHS>8 space tabs, spaces after { ...
<AlmuHS>comments with /* */ ...
<jrtc27>really, go through your own patches with a fine-tooth comb
<jrtc27>look at every line and ask yourself if that is correct
<jrtc27>and make sure you have your editor configured to show tabs distinctly from spaces
<jrtc27>(in vim, set listchars=tab:>- is handy)
<youpi>AlmuHS: best is like jrtc27 said: follow what is majoritarily done around your code
<AlmuHS>yes, but there is not a majority
<AlmuHS>even in same files, there are many styles
<youpi>again, like jrtc27 said
<jrtc27>what did I just say though?
<jrtc27>you're not stupid, use your common sense
<youpi>follow what is next to what you change
<AlmuHS>but in the files wrotten from scratch?
<youpi>I'd say like jrtc27: follow the mach stykle
<AlmuHS>and, what is the mach style?
<jrtc27>and when submitting patches, first impressions are important; if your patches are messy and inconsistent then people take it to be one or both of:
<jrtc27>1. sloppiness, which raises questions about the quality of the code itself
<jrtc27>2. laziness, ie you can't be bothered to check your own patches, so why should someone else bother to invest their time in doing so
<jrtc27>AlmuHS: is probably close enough
<jrtc27>I don't know the specifics of mach
<jrtc27>(FreeBSD has deviated a fair amount from its mach-derived kernel)
<jrtc27>but ultimately just look at the other code
<jrtc27>if it's got tabs for indents and braces on the same lines as if/else then it's trying to be mach style
<jrtc27>so use those files/functions as a reference
<AlmuHS>in i386/i386at/com.c, with Mach copyright, there are this style
<AlmuHS> if (inb(BAUD_MSB(addr)) != 0)
<AlmuHS> {
<AlmuHS> outb(LINE_CTL(addr), oldctl);
<AlmuHS> outb(BAUD_MSB(addr), oldmsb);
<AlmuHS> return 0;
<AlmuHS> }
<AlmuHS>in i386/i386at/autoconf.c this other style
<AlmuHS> for (master = bus_master_init; master->driver; master++)
<AlmuHS> {
<AlmuHS> if (configure_bus_master(master->name, master->address,
<AlmuHS> master->phys_address, i, "atbus"))
<AlmuHS> i++;
<AlmuHS> }
<jrtc27>that first one looks like GNU
<jrtc27>the second one, assuming it's using tabs, looks like mach except { is in the wrong place
<AlmuHS> if (off >= 0xa0000 && off < 0x100000)
<AlmuHS> goto out;
<AlmuHS> p = vm_page_lookup_pa(off);
<AlmuHS> if (p != NULL) {
<AlmuHS> return -1;
<AlmuHS> }
<jrtc27>yes, that's the right style
<jrtc27>go read
<AlmuHS>two one-line if, one with braces, the next not
<jrtc27>one-line ifs are a matter of preference
<jrtc27>often style guides don't enforce one or the other
<AlmuHS>ok, I'll check this
<jrtc27>(e.g. that style(9) says "Braces that are not necessary may be left out.", with "may" not "should"/"must")
<AlmuHS>i'll try to configure my editor
<AlmuHS>i'm using CodeBlocks, a tiny IDE
***Server sets mode: +nt
<damo22>youpi: what should i be calling fsys_init on ? execprocess?
<youpi>the goal is to call into rumpdisk
<youpi>so ext2fs's bootstrap port
<youpi>which is rumpdisk
<damo22>i mean the second param
<damo22>im modifying diskfs_S_fsys_init
<damo22>it seems like it can be done in there
<damo22>since it already inits the proc and auth hurd_ports
<damo22>can i just call fsys_init after it inits the hurd_ports?
<youpi>well, just pass on procserver and authhandle ?
<youpi>since that's what you received
<damo22>do i need to bump the ref counter?
<damo22> err = mach_port_mod_refs (mach_task_self (),
<damo22> procserver, MACH_PORT_RIGHT_SEND, +1); <--- here?
<damo22>i am getting invalid dest port
<youpi>did you use MACH_MSG_TYPE_COPY_SEND ?
<youpi>you shouldn't need to bump the ref by hand
<youpi>see the comment for the bump above: that's only because _hurd_init consumes a ref
<damo22>yes i did
<damo22>(use copy send)
<youpi>is the bootstrap port non-null? (surely it's supposed to, but just to make sure)
<youpi>you could try to use mach_port_mod_refs on the bootstrap and proc ports, to make sure which one might be invalid
<damo22> this is what i changed in boot-start.c
<youpi>you have a port_deallocate(procserver) just above
<youpi>I don't see why so late
<youpi>I don't see why fsys_init would need proc _hurd_ports, you just pass it procserver
<youpi>really, I think you can leave it just where it currently is
<youpi>just moving it out of the if so it's always done
<damo22>so you mean i pass in procserver and set the _hurd_ports inside my fsys_init
<youpi>well, yes, of course
<youpi>I don't see how it'd be otherwise
<youpi>your rump *can't* have _hurd_ports initialized anyway
<youpi>since it's started before everything else
<youpi>so you'll have to set it by hand anyway
<youpi>doing anything later/earlier won't change that
<damo22>but fsys_init is called very late
<youpi>so what?
<damo22>cant the hurd_ports be set already by then?
<youpi>how could it be set?
<youpi>(I mean inside rump)
<youpi>what could possibly set it?
<damo22>is hurd_ports some constant in glibc?
<youpi>sure, but how could it be magically initialized?
<youpi>see what I wrote in bootstrap.html
<youpi>It initializes the default proc and auth ports to be given to processes.
<youpi>but rump is not a child of diskfs
<youpi>so it won't just inherit that
<damo22>but i thought the fsys_init call calls into my rump i dont see where inheritance matters if its just set in glibc
<youpi>what do you mean by "its just set in glibc" ?
<youpi>glibc can't magically know what it's supposed to put in there
<youpi>that's the whole point of fsys_init() to tell boostrap process what they are supposed to put there
<youpi>see how all of auth, exec, proc, startup, diskfs use _hurd_port_set to set it by hand
<damo22>is diskfs_S_fsys_init called before rump's fsys init?
<youpi>precisely because they're all bootstrap process that don't just inherit it from ext2fs
<youpi>errrrr, obviously?
<youpi>the whole point we are dicussing right now is *making* diskfs_S_fsys_init call fsys_init on rump, to trigger an fsys_init call inside rump
<youpi>so of course it'll be called before, since that's what triggers it
<damo22>so diskfs_S_fsys_init can init the _hurd_ports and then call rumps fsys_init
<youpi>or the converse
<youpi>rump won't care what ext2fs has in its _hurd_ports
<damo22>diskfs_S_fsys_init already inits the _hurd_ports, why do i need to write more code to do that in machdev?
<youpi>it's not the same process
<youpi>rump and diskfs have their own _hurd_ports of course
<youpi>they're not the same prtocess
<damo22>oh i didnt know
<damo22>i thought it was a global var
<youpi>there is no such thing as a global variablke that would be shared by all processess
<youpi>really not
<youpi>definitely not
<damo22>yeah sorry
<youpi>I mean, that's basic C
<youpi>I'm amazed how much you can be brilliant, and at the same time lack some pieces of basic knowledge
<damo22>but there are some global vars in glibc
<youpi>there's really things wrong going on in computer science courses
<youpi>yes, global to the process
<youpi>so each process has to have it initialized
<damo22>i never took a comp sci course
<youpi>that can explain a few things :)
<damo22>i did a math degree
<damo22>taught myself how to program by playing with code
<youpi>you didn't read any book?
<damo22>i read a few tutorials sure
<damo22>not solid reference books
<youpi>you really should read at least a couple of books for the basic things
<youpi>otherwise you'll miss such kind of important information
<damo22>maybe you can help me choose something to read some time
<youpi>I can mostly advise what I read myself
<youpi>the 3 Tanenbaum books: Operating systems, Networks, Architectures
<youpi>the Douglas Comer book TCP/IP networking
<youpi>Rubini&Corbet's book: Linux Device Drivers
<youpi>is a very interesting read as well
<damo22>will save these for later
<youpi>it's not that much about Linux in particular, but on drivers in general
<youpi>(that one is available as PDF iirc)
<damo22>i started programming at 10 on MS-DOS: GWBASIC
<youpi>I started on a CPC-6128 :)
<youpi>that wasn't really GWBASIC, but very similar
<youpi>ah, you may also want to read the Minix book from Tanenbamu
<damo22>at one time i was using windows, macos and "linux" (all at the same time) and then i discovered GNU and decided to ditch proprietary software
<damo22>youpi: how do i get a root_pt (port for root directory) ? do i need to copy code from diskfs_make_peropen ?
<youpi>oh right you'll need to get that from ext2fs as well
<youpi>you are getting an fsys_startup call, right?
<youpi>that gives you a control port on ext2fs
<damo22>ok yes
<youpi>you can then use fsys_getroot() to get a port on the root
<youpi>see diskfs_start_bootstrap doing it for exec
<youpi>(you can pass a null port for the dotdot)
<damo22>i am creating a new root directory node ?
<damo22>and creating a port to access it
<youpi>you don't need a new root directory node
<youpi>you're just asking ext2fs a port on the root of the / FS
<youpi>that you can install as CRDIR and CWDIR
<damo22>fsys_getroot (diskfs_exec_ctl, root_pt <--- but i need one of these
<AlmuHS>jrt25: tonight I tried to fix the format in one of my project files. Check it the format is correct
<AlmuHS>if yes, I will apply the same format for the rest of the files
<youpi>damo22: see the definition of fsys_getroot in fsys.defs
<youpi>when I talked about dotdot, I was talking about that definition
<youpi>so in your fsys_getroot call example it's root_pt
<gnu_srs>youpi: If I put printfs in proc/wait.c:S_proc_wait() do I have to rebuild libc, i.e. RPC_proc_wait.c?
<youpi>? no
<youpi>RPC_proc_wait.c is just the client side
<youpi>the .c file won't be modified
<youpi>S_proc_wait() is the server side
<youpi>it's compiled entirely separately
<youpi>*and* they both execute in different processes!
<youpi>so there's no reason why changing one side would require rebuilding the other side
<youpi>that being said, as I already said mach_print should be just working
<youpi>if it's not, that must be for a trivial reason
<jrtc27>AlmuHS: it's a lot better than what I remember, but still a few places (a few blank lines that shouldn't be there, you still have a few instances of "if(", it's "} else" with no new line, * should always have a space before it and don't put a space before the "(" in function definitions/declarations)
<AlmuHS>thanks, I'll check again
***jma is now known as junlingm
<junlingm>youpi: I am a litle bit confused by the new device_intr_ack and device_intro_notify routines. now every device has the two routines. But isn't the service only available from the irq device? Should all other device return not supported?
<youpi>actually yes
<youpi>I hadn't realized that it would incur that, not really pretty but well
<AlmuHS>i've just send a new patches set to the maillist
<AlmuHS>i fixed the formatting
<junlingm>Youpi: Would it make sense if we implement an interrupt line as a regular character device node, and a program may select on it to wait for an interrupt. When an interrupt occurs, there would be a character available, and read it off would mean to ack it?
<youpi>there could be some idea there yes
<youpi>making the read do the acknowledge would not be convenient
<youpi>I don't think the device_read() RPC allows to separate out checking whether data is available, and reading it
<youpi>but a device_write() could be used for that
<youpi>at least, now we have something that works reasonably well :)
<youpi>but feel free to play with something that would be better and replace it
<junlingm>indeed. It is just a tiny little inconvenient to write a transalator for device :) The main problem is conceptual confusion.
<youpi>well, in the concept it's fine, it should just probably have gone to another interface, like we have a separate interface for the i386 perms
<youpi>and we could move the support from the device master port to an opened device without troubles
<junlingm>yes gone to another interface makes more sense.